Description
For some use cases, the default settings of UsageTrackingFilterCachingPolicy are inappropriate. It would be ideal if those settings were configurable.
For example, the default configuration includes a history that looks at the last 256 filters. In the extreme case, if you had a stream of fairly complicated filters where the total number of distinct filters was significantly greater than 256, then you'd never get caching of any filters!
In a real world example, we just went through an upgrade from ES 1.7 to 2.1.1 and experienced pretty severe degradation of response times. Analysis of the query_cache indicated that a) the cache was relatively sparsely populated; b) the miss ratio was very high. Our particular use case was not well handled b/c we filter documents using arbitrary boolean combinations of ~1k terms. As best as I could tell, the limited 256 history size meant that we were only caching the very most common terms. Inefficient caching combined with a fairly large document count led to increased response times across the board and very painful response times under heavier load.
Tellingly, what rescued performance was completely bypassing the usage-based cache via the undocumented index.queries.cache.everything: true setting and relying purely on the LRU-nature of the cache to keep the most useful filters around.
Tuning the usage policy would be great. And, arguably, documented support of a policy that simply relies on using LRU to determine the useful filters would also be a good idea. (It did not escape my attention that the index.queries.cache.everything setting appears to have only been added for testing purposes!)