Hoss, I can't see why Network IO is the issue as the shards and the front end SOLR resided on the same server. I said "resided", because I got rid of the front end (which according to my measurements, was taking at least as much time for merging as it took to find the actual data in the shards) and shards. Now I have only one shard having all the data. Filter cache tuning also helped to reduce the amount of evictions to a minimum.
Dmitry On Fri, Dec 9, 2011 at 10:42 PM, Chris Hostetter <hossman_luc...@fucit.org>wrote: > > : The culprit seems to be the merger (frontend) SOLR. Talking to one shard > : directly takes substantially less time (1-2 sec). > ... > : >> > > >>facet.limit=500000 > > Your probably most likeley has very little to do with your caches at all > -- a facet.limit that high requires sending a very large amount of data > over the wire, multiplied by the number of shards, multipled by some > constant (i think it's 2 but it might be higher) in order to "over > request" facet constriant counts from each shard to aggregate them. > > the dominant factor in the slow speed you are seeing is most likeley > Network IO between the shards. > > > > -Hoss > -- Regards, Dmitry Kan
