There are some gains to be made in Solr's distributed search code. A few weeks about I spent time profiling dist search using dtrace/btrace and found some areas for improvement. I planned on writing up some blog posts and providing patches but I'll list them off now in case others have input.
1) Disable the http client stale check. It is known to cause latency issues. Doing this gave be a 4x increase in perf. 2) Disable nagle, many tiny packets are not being sent (to my knowledge), so don't wait. 3) Use a single TermEnum for all external id->lucene id lookups. This seemed to reduce total bytes read according to dtrace. 4) Building off #3, cache a certain number of external id->lucene id. Avoding the TermEnum altogether. 5) If fl=id is present then dont' run the 2nd phase of the dist search. I'm still very new to Solr so there could be issues with any of the patches I propose above that I'm not aware of. Would love to hear input. -Z On Wed, Dec 5, 2012 at 8:35 PM, sausarkar <sausar...@ebay.com> wrote: > We are using SolrCloud and trying to configure it for testing purposes, we > are seeing that the average query time is increasing if we have more than > one node in the SolrCloud cluster. We have a single shard 12 gigs > index.Example:1 node, average query time *~28 msec* , load 140 > queries/second3 nodes, average query time *~110 msec*, load 420 > queries/second distributed equally on three servers so essentially 140 qps > on each node.Is there any inter node communication going on for queries, is > there any setting on the Solrcloud for query tuning for a cloud config > with > multiple nodes.Please help. > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/SolrCloud-Query-performance-degrades-with-multiple-servers-tp4024660.html > Sent from the Solr - User mailing list archive at Nabble.com.
