bq: How could I overlook it? Easy, the same way I did for a year and more <G>....
Best Erick On Tue, Feb 21, 2012 at 6:50 PM, Em <mailformailingli...@yahoo.de> wrote: > 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. >>>> >>
