We sort by default on "name", which varies quite a bit (we're never going to make sorting by field go away).
The thing is solr has been pretty amazing across 1 million records. Now that we've doubled the size of the dataset things are definitely slower in a nonlinear way...I'm wondering what factors are involved here. -Steve On Fri, Mar 27, 2009 at 6:58 PM, Otis Gospodnetic <otis_gospodne...@yahoo.com> wrote: > > OK, we are a step closer. Sorting makes things slower. What field(s) do you > sort on, what are their types, and if there is a date in there, are the dates > very granular, and if they are, do you really need them to be that precise? > > > Otis > -- > Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch > > > > ----- Original Message ---- >> From: Steve Conover <scono...@gmail.com> >> To: solr-user@lucene.apache.org >> Sent: Friday, March 27, 2009 1:51:14 PM >> Subject: Re: optimization advice? >> >> > Steve, >> > >> > Maybe you can tell us about: >> >> sure >> >> > - your hardware >> >> 2.5GB RAM, pretty modern virtual servers >> >> > - query rate >> >> Let's say a few queries per second max... < 4 >> >> And in general the challenge is to get latency on any given query down >> to something very low - we don't have to worry about a huge amount of >> load at the moment. >> >> > - document cache and query cache settings >> >> >> class="solr.LRUCache" >> size="512" >> initialSize="512" >> autowarmCount="256"/> >> >> >> class="solr.LRUCache" >> size="512" >> initialSize="512" >> autowarmCount="0"/> >> >> > - your current response times >> >> This depends on the query. For queries that involve a total record >> count of < 1 million, we often see < 10ms response times, up to >> 4-500ms in the worst case. When we do a page one, sorted query on our >> full record set of 2 million+ records, response times can get up into >> 2+ seconds. >> >> > - any pain points, any slow query patterns >> >> Something that can't be emphasized enough is that we can't predict >> what records people will want. Almost every query is aimed at a >> different set of records. >> >> -Steve > >
