Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsSolr’s three main search caches reuse different things: filterCache reuses matching-document sets, queryResultCache reuses ordered result lists, and documentCache reuses loaded documents and their stored fields. They belong to an Index Searcher, so their usefulness depends on repeated query patterns, memory use, and what happens when Solr opens a new searcher.
How the three Solr caches differ
Think of the caches as working at three distinct stages: identifying which documents match a condition, reusing a particular ordered page of results, and retrieving stored fields for documents. A cache hit in one does not mean the other two have also hit.
| # | Preview | Product | Price | |
|---|---|---|---|---|
| 1 |
|
Apache Solr Enterprise Search Server | $49.99 | Buy on Amazon |
| 2 |
|
Apache Solr 3 Enterprise Search Server | $19.17 | Buy on Amazon |
| 3 |
|
Apache Solr for Indexing Data | $40.99 | Buy on Amazon |
| 4 |
|
Apache Solr High Performance | $35.45 | Buy on Amazon |
| 5 |
|
Apache Solr: A Practical Approach to Enterprise Search | $48.67 | Buy on Amazon |
| Cache | What it stores | Typical reuse |
|---|---|---|
filterCache |
Parsed queries paired with unordered sets of matching documents. | Repeated filter queries, commonly fq parameters. |
queryResultCache |
Ordered lists of document IDs (DocList) for a query, sort, and requested result range. | Repeated searches that request the same result list. |
documentCache |
Lucene Document objects containing stored fields. |
Retrieving stored fields for documents needed by search results. |
These definitions and behaviors are described in the Apache Solr Reference Guide: Caches and Query Warming. The guide is rolling documentation, so consult the version matching your deployment for exact defaults and supported settings.
What filterCache does
filterCache keeps parsed queries and unordered sets of every document that matches them. It commonly serves filter queries supplied with fq. By default, separate fq parameters are cached independently, and Solr intersects their matching sets to produce the filtered result.
Recommended Free Tools
#1 Best Overall
Choosing separate or combined filters
Keep filters separate when they are independently useful across requests—for example, when a category filter appears with many different brand filters. If several clauses are almost always used together, combining them may avoid caching sets that are rarely reused individually. Solr’s Common Query Parameters guide explains the behavior of multiple fq parameters.
In the default Lucene query parser, filter(...) syntax can mark clauses for filter-cache use individually. A local parameter such as cache=false can bypass the filter cache for a filter unlikely to recur. Bypassing avoids spending cache space on one-off filters; repeated filters are the more plausible candidates for reuse. The Solr cache guide also documents filter-cache use for faceting with facet.method=fc.
What queryResultCache does
queryResultCache stores ordered document-ID lists, or DocLists, for prior searches. Its result depends on the query, sort order, and requested range, so it is not interchangeable with the unordered matching set in filterCache.
Result windows and entry limits
queryResultWindowSize can let Solr cache a superset of the page requested. In the Solr guide’s example, a request for documents 10–19 with a window size of 50 can cache documents 0–49. This may help when users page through nearby results, but a larger window also means more document IDs held for an entry. queryResultMaxDocsCached limits how many documents any one entry can hold.
Free tools Windows power users keep installed
One-click scans. No signup required.
What documentCache does
documentCache holds Lucene Document instances containing stored fields. It helps when Solr needs to load stored-field documents for results; it does not cache the matching set or the ordered result list.
The Solr guide advises sizing this cache above max_results × max_concurrent_queries so a request does not have to refetch a document. Treat that as a sizing guideline to validate against your own concurrency and result limits, not a universal optimum. More stored fields increase memory use. Do not set maxRamMB for this cache: Solr warns that its memory consumption is not calculated properly and it can use substantially more memory than anticipated.
Rank #3
Searcher lifecycle, warming, and eviction
Each cache is attached to an Index Searcher and its fixed view of the index. Entries remain valid for that searcher’s lifetime. When Solr opens a new searcher, the current one can continue serving requests while the new searcher warms; once ready, the new searcher handles requests, and the old one closes after outstanding requests finish. A commit clears caches, which then need to be populated again.
For CaffeineCache, autowarmCount accepts an integer or a percentage. Auto-warming can copy entries from the old searcher’s cache to the new one; this can reduce the initial cold-cache period, but it also has a cost and should be considered alongside searcher readiness needs.
The guide describes CaffeineCache eviction as Window TinyLFU, which weighs frequency and recency. It also documents async as enabled by default; asynchronous behavior can help if concurrent queries request the same result set before it is cached. Child-document and join queries require async cache enabled. Check the documentation for your installed Solr release rather than assuming defaults from the rolling guide apply unchanged.
Rank #4
maxIdleTime is measured in seconds; zero disables idle-time eviction. Solr gives 60–3600 seconds as a workload-dependent range and warns that an overly short idle timeout can cause repeated eviction and misses. Where both size and maxRamMB apply to a supported cache, the RAM limit takes precedence. These are configuration controls, not values that are automatically right for every workload.
How to measure and tune cache sizes
There is no universal cache size that suits every Solr index or query mix. Tune against repeated workload patterns, memory footprint, and searcher warm-up behavior, and evaluate each cache separately.
1. Establish the workload and configuration
- Identify queries and filters that recur, including whether filters are reused independently or almost always together.
- Record result sizes, sorts, and requested ranges that may affect query-result reuse.
- Review stored-field volume, result limits, and concurrency when sizing
documentCache. - Use the cache properties appropriate to the deployed release. The Solr Config API documents properties including class, size, initial size, auto-warm count, maximum RAM, and regenerator for these caches.
2. Inspect cache metrics
The Solr performance reference lists cache operations (inserts and evictions), lookups (hits and misses), current entries, and RAM bytes used. Its example requests cache metrics with /solr/admin/metrics?category=CACHE. Metrics are per core; in SolrCloud, they correspond to an individual replica. Preserve that scope when comparing results so a busy replica is not hidden by an aggregate across cores or replicas. See the Performance Statistics Reference.
Best Value
Solr 10 introduced metric-name and endpoint changes, and the rolling metrics guide labels metrics Beta and subject to change in minor releases. Check the documentation for the installed version before building dashboards or relying on specific metric names.
3. Interpret the measures together
- Hit ratio and memory footprint: A low hit ratio alongside a large configured cache may suggest memory could be reclaimed. A low hit ratio by itself is not evidence of a problem if queries seldom repeat.
- Evictions and query repetition: Frequent evictions can indicate that a cache is too small for a repeating working set, but verify that the workload actually repeats before increasing capacity.
- Warm-up time and readiness: Compare the time and cost of warming entries with the time a new searcher needs to become ready for requests.
- Cache types and deployment scope: Compare filter, query-result, and document caches separately, and examine individual cores or SolrCloud replicas rather than relying only on pooled totals.
4. Change one setting and validate
Adjust a relevant size, window, idle timeout, or warm-up setting based on the observed bottleneck, then compare hits, misses, evictions, memory, and warm-up behavior under a representative workload. Retain the change only if it improves the outcome that matters without unacceptable memory use or searcher-startup cost.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
