Hi, Andy. It seems reasonable to me. To count facets Solr needs docsets of results for in-order processing. I suppose, SimpleFacets code can be amended so it keeps the result docset out of filter cache, but would it get significant gain? Why do you think that thousands of evictions is a bad thing?
On Wed, Nov 16, 2022 at 8:26 PM Andy Lester <a...@petdance.com> wrote: > I've been working on tuning my filter cache, and have discovered that > doing a search with facet=on results in an entry in the filter cache for > the q parameter. This makes no sense to me. Is this intentional? > > In my app, there are only a couple of dozen possible FQs that can get > passed to Solr. There are no restrictions on the Q. The result is that I > have many added keys to the filter cache, and many evictions. I should be > able to get by with a filterCache size of 100, but even with a filterCache > size of 5000 I get thousands of evictions per hour because of all the > unique Q arguments getting added. > > If it is intentional, then we need to update the docs for both faceting > and the filter cache to explain the behavior. This is something that users > will need to take in to account when planning and tuning caches. > > If this behavior is not intentional and is a bug, it seems like fixing it > would be an easy performance win. > > I've made a ticket for this at > https://issues.apache.org/jira/browse/SOLR-16546 It illustrates the > specific steps I've taken to demonstrate the behavior. The demonstration is > on Solr 9.0.0 and uses Shawn Heisey's filter cache dumper for illustration, > but it also happens on a stock 8.11.2 install. > > Thanks, > Andy > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > > -- Sincerely yours Mikhail Khludnev