I can't give you a definitive answer based on the data you've provided. However, do you really need to get *all* facets? Can't you limit them with facet.limit field? Are you planning to run multiple *:* queries with all facets turned on a 58GB index in a live system? I don't think that's a good idea.
As for the 125 seconds, I think it is probably because of paging issues. Are you faceting on multivalued or tokenized fields? In that case, Solr uses field queries which consume a lot of memory if the number of unique terms are large. On Jan 31, 2008 9:13 PM, Andy Blower <[EMAIL PROTECTED]> wrote: > > I'm evaluating SOLR/Lucene for our needs and currently looking at > performance > since 99% of the functionality we're looking for is provided. The index > contains 18.4 Million records and is 58Gb in size. Most queries are > acceptably quick, once the filters are cached. The filters select one or > more of three subsets of the data and then intersect from around 15 other > subsets of data depending on a user subscription. > > We're returning facets on several fields, and sometimes a blank (q=*:*) > query is run purely to get the facets for all of the data that the user > can > access. This information is turned into browse information and can be > different for each user. > > Running performance tests using jMeter sequentially with a single user, > these blank queries are slower than the normal queries, but still in the > 1-4sec range. Unfortunately if I increase the number of test threads so > that > more than one of the blank queries is submitted while one is already being > processed, everything grinds to a halt and the responses to these blank > queries can take up to 125secs to be returned! > > This surprises me because the filter query submitted has usually already > been submitted along with a normal query, and so should be cached in the > filter cache. Surely all solr needs to do is return a handful of fields > for > the first 100 records in the list from the cache - or so I thought. > > Can anyone tell me what might be causing this dramatic slowdown? Any > suggestions for solutions would be gratefully received. > > > Thans > Andy. > -- > View this message in context: > http://www.nabble.com/Slow-response-times-using-*%3A*-tp15206563p15206563.html > Sent from the Solr - User mailing list archive at Nabble.com. > > -- Regards, Shalin Shekhar Mangar.
