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.
