: Although I don't have statistics to back my claim, I suspect that the really : nasty filters don't have as high a hitcount as the ones that are more simple. : Typically the really nasty filters are used when an employee logs into the : site. Employees have access to a lot more than customers do, but the search : still needs to be filtered to be appropriate for whatever search options are : active.
A low impact change to consider would be to leverage the "cache=false" local param feature that was added in Solr 3.4... https://wiki.apache.org/solr/CommonQueryParameters#Caching_of_filters ...you could add this localparam anytime you know the query is coming from an employee -- or anytime you know the filter query is "esoteric" A higher impact change would be to create a dedicated query slave machine (or just an alternate core name that polls the same master) that is *only* used by employees and has much lower sizes on the caches -- this is the approach i have advocated and seen work very well since the pre-apache days of Solr: dedicated instances for each major "user base" with key settings (ie: replication frequencies, cache sizes, cache warming, static warming of sorts, etc...) tuned for that user base. -Hoss
