See if this one makes it through: bq: Sorting 4 million values really shouldn't take that long
True. But transmitting 100,010 results back to the originating machine from each of 40 machines, unpacking them and _then_ sorting them could be another story <G>... Erick On Tue, Mar 26, 2013 at 5:07 PM, Michael Ryan <mr...@moreover.com> wrote: > Depending on your use case and the particulars of your system, a previous > post I made about using a FieldCache in SolrIndexSearcher for id retrieval > (see http://osdir.com/ml/solr-user.lucene.apache.org/2013-01/msg01574.html) > may help you. In your case, it might not be the merging process on the > controller itself that is the slow point, but rather the retrieval of 100,000 > documents on each of your 40 shards. It may seem that your shards are > responding in < 10ms based on QTime, but the actual time spent retrieving the > docs from disk is not included in that figure. > > If it really is the merging time on the controller that is the slow point, I > would think that could also be improved. Sorting 4 million values really > shouldn't take that long... > > -Michael > > -----Original Message----- > From: qungg [mailto:qzheng1...@gmail.com] > Sent: Tuesday, March 26, 2013 2:55 PM > To: solr-user@lucene.apache.org > Subject: RE: Slow performance on distributed search > > for start=100,000&row=10. event though each individual shard take only < 10ms > to query, the merging process done by controller would take about a minutes. > > By looking at logs, each shard is giving the controller shard 100,010 rows of > data, and because there are 40 shards in total, the controller is getting > 100,010*40 rows of data, therefore merging is taking a long time. > > I have not tried solr cloud, does any one know the performance of query large > start row on solr cloud? > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/Slow-performance-on-distributed-search-tp4051434p4051492.html > Sent from the Solr - User mailing list archive at Nabble.com.
