Thanks for the details! I think I understand better now. And regarding the proxy caching, the goal wasn't speedup in that area. It was to decrease memory footprint allowing a larger cache.
-T -----Original Message----- From: Chris Hostetter [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 29, 2008 9:09 PM To: solr-dev@lucene.apache.org Subject: RE: Query Cache Memory Usage - Could it be better? : Worst case scenario (and most frequent) my DisMax queries are using up : to 5 query fields (qf) with different boosts associated with them. They : are also have up to 4 phrase fields (pf) to boost if terms are found : close to each other. The minimum match (mm) is varying from 1 to 100%. so assuming your field names are an average for 10 characters long, each field boost is a number about 2 chars long, and your user input is an average of 7 characters long (numbers i'm just randomly pulling out of thin air) a standard query string (not on the default field) would be 10+1+7=18 chars, while a dismax string would be (5+1+2+1)*(5+4)=81 chars ... 18/81 is amazingly almost the exact the same ratio as what you saw between the memory size for a standard query and a dismax query. (i swear i didn't pick those numbers to make it work out that way) but on to the real question of using string keys instead of Query objects as keys... : So, if there is no canonical representation, than shouldn't the original : query URL be enough to reproduce the query, as well as act as a cache : key? I do see some overhead in parsing the query again, but that should the query cache is a more granular cache then that ... there might be multiple queries executed by any one handler, and each get cached independently. custom handlers might even have behavior which isn't deterministic based on the URL (i've got some that use params to pick a doc in the index, and that doc contains metadata which then drives additional queries -- the metadata doc might change even if the URL didn't) If you want caching at a granularity of hte URL as a string, putting an HTTP "accelerator" cache (aka: "proxy cache" or "reverse cache proxy") in front of solr might be more along the lines of what you are looking for. -Hoss
