Erick, damn!
The NOW of now isn't the same NOW a second later. So obvisiously. How could I overlook it? Kind regards, Em Am 22.02.2012 00:17, schrieb Erick Erickson: > Be a little careful here. Any "fq" that references NOW will probably > NOT be effectively cached. Think of the fq cache as a map, with > the key being the fq clause and the value being the set of > documents that match that value. > > So something like NOW gives > 2012-01-23T00:00:00Z > but issuing that a second later gives: > 2012-01-23T00:00:01Z > > so the keys don't match, they're considered > different fq clauses and the calculations are all > done all over again. > > Using the rounding for date math will help here, > something like NOW/DAY+1DAY to get midnight tonight > will give you something that's re-used, similarly for > NOW/DAY-30DAY etc. > > All that said, your query times are pretty long. I doubt > that your fq clause is really the culprit here. You need > to find out what the bottleneck is here, consider using > jconsole to see what your machine is occupying its > time with. Examine your cache statistics to see > if your getting good usage from your cache. You > haven't detailed what you're measuring. If this is just > a half-dozen queries after starting Solr, you may get > much better performance if you autowarm. > > You may have too little memory allocated. You may be > swapping to disk a lot. You may..... > > What have you tried and what have the results been? > > In short, these times are very suspect and you haven't > really provided much info to go on. > > Best > Erick > > On Tue, Feb 21, 2012 at 5:25 PM, Em <mailformailingli...@yahoo.de> wrote: >> Hi, >> >>> But they [the cache configurations] are default for both tests, can it >> affect on >>> results? >> Yes, they affect both results. Try to increase the values for >> queryResultCache and documentCache from 512 to 1024 (provided that you >> got two distinct queries "bay" and "girl"). In general they should fit >> the amount of documents and results you are expecting to have in a way >> that chances are good to have a cache-hit. >> >>> Maybe it is that I use shards. I have 11 shards, summary ~310M docs. >> 11 shards on the same machine? Could lead to decreased performance due >> to disk-io. >> >> Did you tried my advice of adjusting the precisionSteps of your >> TrieDateFields and reindexed your documents afterwards? >> >> Kind regards, >> Em >> >> >> Am 21.02.2012 22:52, schrieb ku3ia: >>> Hi, >>> >>>>> First: I am really surprised that the difference between explicit >>>>> Date-Values and the more friendly date-keywords is that large. >>> Maybe it is that I use shards. I have 11 shards, summary ~310M docs. >>> >>>>> Did you made a server restart between both tests? >>> I tried to run these test one after another, I'd rebooted my tomcats, I'd >>> run second test first and vice versa. >>> >>>>> Second: Could you show us your solrconfig to make sure that your caches >>>>> are configured well? >>> I'm using solrconfig from solr/example directory. The difference is that I >>> only commented out unused components. Filter, document and query result >>> cache is default. But they are default for both tests, can it affect on >>> results? >>> >>>>> Furthermore: Take into consideration, whether you really need 500 rows >>>>> per request. >>> Yes, I need 500 rows. >>> >>> Thanks >>> >>> -- >>> View this message in context: >>> http://lucene.472066.n3.nabble.com/Date-filter-query-tp3764349p3764941.html >>> Sent from the Solr - User mailing list archive at Nabble.com. >>> >
