On May 31, 2011, at 2:02 PM, Markus Jelsma wrote: > the cumulative hit > ratio of the query result cache, it's almost never higher than 50%. > > What are your stats? How do you deal with it?
warmupTime : 0 cumulative_lookups : 394867 cumulative_hits : 394780 cumulative_hitratio : 0.99 cumulative_inserts : 87 cumulative_evictions : 0 Of course, that's shortly after I ran a query-intensive, not very creative load test (thousands of identical queries of a not very changeable data set). As a matter of fact, the numbers say I had exactly one miss after each insert, and everything else was a cache hit. Which makes perfect sense, for my (really dumb) test case. > In some cases i have to disable it because of the high warming penalty i get > in a frequently changing index. This penalty is worse than the very little > performance gain i get. Different users accidentally using the same query or > a > single user that's actually browsing the result set only happens very > occasionally. And if i wanted the hit ratio to climb i'd have to increase the > cache size and warming size to absurd values, only then i might just reach > about 60% hit ratio. If you have humans randomizing the query stream, I'm sure you're right. If you're convinced your queries are unrelated and variable, why would you expect a query cache to help at all? On the other hand, I actually plan to use my Solr base to drive a UI, where the query parameters never change, and the data underneath changes mostly in bursts (generally near the end of the work day), so I suspect I'll only see misses after a document add, while lookups ten to cluster early in the day. So I actually am hoping for a high hit ratio. -==- Jack Repenning Technologist Codesion Business Unit CollabNet, Inc. 8000 Marina Boulevard, Suite 600 Brisbane, California 94005 office: +1 650.228.2562 twitter: http://twitter.com/jrep
PGP.sig
Description: This is a digitally signed message part
