10-20-2026, 07:31 AM
Measured tuning workflow for Varnish Cache by Adminforum 0.5.0 lab preview. Reviewed 20 October 2026.
Fine-tuning starts with correct content and repeatable measurements. A high hit percentage is not useful if someone receives the wrong account page, sees stale prices or loses access to a website. This guide explains the observations available now and separates them from settings planned for a later release.
Start here: Configuration, templates and exclusions walkthrough.
1. Know which settings are adjustable
In the current addon you can select a path template, add exclusions, enable or disable fixture caching, purge one exact URL and read the available counters/logs.
Cache allocation is fixed at 32 MiB. The maximum positive public-response lifetime is 60 seconds. Grace is explicitly zero. There is no memory, TTL, grace, worker-thread or timeout editor in this release. These values describe the synthetic fixture; they are not recommended production settings. Do not edit generated VCL or daemon arguments behind the addon and assume it will retain or validate those edits.
2. Record a baseline before changing policy
Use a repeatable, anonymous public page and a consistent client, concurrency and request headers. Record direct responses, cold misses and prefilled warm hits separately. Include errors and p95, not just the fastest response. Keep PHP/database/CDN changes out of the comparison so the cause is clear.
Our before-and-after lab report measured 1,440 successful requests. At concurrency 1, direct mean was 1.707 ms, cold MISS 2.651 ms and warm HIT 0.896 ms. At concurrency 4, direct mean was 5.906 ms, cold MISS 6.671 ms and warm HIT 3.350 ms. Compare within the same concurrency group. Those tiny loopback timings are not browser load times or production capacity estimates.
3. Diagnose low hit rate before allocating more memory
Refresh Overview, then inspect Access Logs. Classify the outcome:
- Mostly BYPASS: inspect cookies, authorization, private-response headers, query strings and exclusions. Extra memory will not turn an intentionally private response into a cacheable page.
- Mostly MISS on distinct URLs: new objects need an initial fill. Repeating the same eligible URL is the first useful check.
- MISS after expiry, a purge or a rules update: this may be expected. Rules updates create a new cache namespace.
- Repeated MISS on the same URL before expected expiry: check response eligibility, variant headers, actual host/scheme, intervening restarts and evictions.
- No request rows: confirm caching is enabled, the request reaches the test instance and logs were refreshed. Direct routing does not appear in Varnish's request sample.
The displayed hit ratio uses HIT / (HIT + MISS), excluding bypassed traffic. For example, 80 hits and 20 misses gives 80%, even if another 900 requests bypassed. Do not describe that figure as the percentage of all website visitors served from cache. Counters reset when the Varnish child restarts; compare counter differences over a known interval rather than unrelated totals.
4. Read memory and eviction figures correctly
Open Storage after starting the fixture. Read allocated storage, limit, cached objects and evictions together.
![[Image: attachment.php?aid=399]](https://adminsforum.com/attachment.php?aid=399)
These figures belong to the dedicated test instance. They are not per-domain disk usage.
The 32 MiB cache allocation is not a cap on total process memory. Process RSS is shown separately and includes more than cached response bodies. Leave room for the operating system, PHP workers, database, webserver and Varnish overhead when planning a later deployment. Varnish's storage documentation explains the additional allocations and allocator overhead; choosing a cache size equal to all free RAM is not a sizing method.
A growing eviction counter means objects have been evicted to make room. Record the increase during a representative workload. If useful frequently requested objects are evicted before reuse, capacity or the cached object mix deserves investigation. A single nonzero lifetime counter is not proof that the cache is too small. If objects expire before being reused, simply increasing capacity may not help.
5. Balance freshness with cache lifetime
TTL is the period a cached object can normally remain fresh. A longer value can reduce origin fetches but can also keep old public content visible longer unless it is invalidated. Determine how quickly a changed article, price, availability or announcement must appear before choosing a policy.
In this preview, successful explicitly public responses need a positive lifetime and are capped at 60 seconds. The addon does not give you a field to increase it. Test a changed public response with the exact-URL purge control and confirm that the next request gets the new content. A full-site purge and automatic WordPress invalidation are not implemented. Do not promise immediate updates across a whole site from a single-path purge.
6. Understand grace before requesting it
Varnish supports grace: eligible stale content can be served for an additional period while a fresh version is fetched. Keep has a different purpose: retaining an object for conditional revalidation. These are content-freshness choices, not universal speed switches. This addon currently sets grace to zero; it does not expose or validate a production stale-content policy. Consider such a feature only after its behavior and acceptable staleness have been tested for the application.
7. Tune the origin when misses are slow
If direct and MISS requests are slow while HIT is fast, investigate the work still required at the origin. Correlate the same time window with PHP slow requests, database slow queries, CPU, available RAM, swap activity and storage I/O. A Varnish HIT avoids that work for an eligible cached response; it does not repair slow authenticated pages or unsafe application queries.
Do not apply a universal PHP worker count or database buffer size from this guide. Measure the application's worker memory, database working set and server capacity first. Make one change at a time and compare the same workload, including errors. If direct requests are already fast, cold-cache overhead may exceed any benefit for a rarely reused URL.
8. Use errors and logs to choose the next action
- 4xx: check the requested path, access restrictions and application response. Do not disable private-page rules to hide an authorization error.
- 5xx: check the origin and relevant web/PHP error logs, then correlate with addon Activity. The addon Error Logs tab is a sample, not the full server log.
- Online - fallback / Needs attention: disable fixture caching, verify direct routing, then investigate the cache service. Availability and active caching are separate checks.
- Template did not save: read the validation message, correct unsupported path syntax, then apply and refresh. Do not assume a failed save changed the active policy.
9. Re-test privacy after each policy change
Check anonymous public pages, logged-in pages, two independent test users, cart/account/checkout pages, APIs, query-string URLs and responses that set cookies. Use disposable sessions and never publish their headers. Our existing fixture checks prove synthetic bypass behavior; real WordPress/WooCommerce and Laravel session isolation remain release gates. Template names alone are not proof of compatibility.
10. Keep a small change record
Retain the change only when it improves the intended workload without correctness or availability regressions. Stop the isolated test website after the exercise. Public deployment also needs a supported engine, tested installer, real-site routing and recovery; this preview is not that release.
References: Varnish storage backends; grace and keep.
Original AdminsForum lab screenshot. Copyright AdminsForum | adminsforum.com.
Fine-tuning starts with correct content and repeatable measurements. A high hit percentage is not useful if someone receives the wrong account page, sees stale prices or loses access to a website. This guide explains the observations available now and separates them from settings planned for a later release.
Start here: Configuration, templates and exclusions walkthrough.
1. Know which settings are adjustable
In the current addon you can select a path template, add exclusions, enable or disable fixture caching, purge one exact URL and read the available counters/logs.
Cache allocation is fixed at 32 MiB. The maximum positive public-response lifetime is 60 seconds. Grace is explicitly zero. There is no memory, TTL, grace, worker-thread or timeout editor in this release. These values describe the synthetic fixture; they are not recommended production settings. Do not edit generated VCL or daemon arguments behind the addon and assume it will retain or validate those edits.
2. Record a baseline before changing policy
Use a repeatable, anonymous public page and a consistent client, concurrency and request headers. Record direct responses, cold misses and prefilled warm hits separately. Include errors and p95, not just the fastest response. Keep PHP/database/CDN changes out of the comparison so the cause is clear.
Our before-and-after lab report measured 1,440 successful requests. At concurrency 1, direct mean was 1.707 ms, cold MISS 2.651 ms and warm HIT 0.896 ms. At concurrency 4, direct mean was 5.906 ms, cold MISS 6.671 ms and warm HIT 3.350 ms. Compare within the same concurrency group. Those tiny loopback timings are not browser load times or production capacity estimates.
3. Diagnose low hit rate before allocating more memory
Refresh Overview, then inspect Access Logs. Classify the outcome:
- Mostly BYPASS: inspect cookies, authorization, private-response headers, query strings and exclusions. Extra memory will not turn an intentionally private response into a cacheable page.
- Mostly MISS on distinct URLs: new objects need an initial fill. Repeating the same eligible URL is the first useful check.
- MISS after expiry, a purge or a rules update: this may be expected. Rules updates create a new cache namespace.
- Repeated MISS on the same URL before expected expiry: check response eligibility, variant headers, actual host/scheme, intervening restarts and evictions.
- No request rows: confirm caching is enabled, the request reaches the test instance and logs were refreshed. Direct routing does not appear in Varnish's request sample.
The displayed hit ratio uses HIT / (HIT + MISS), excluding bypassed traffic. For example, 80 hits and 20 misses gives 80%, even if another 900 requests bypassed. Do not describe that figure as the percentage of all website visitors served from cache. Counters reset when the Varnish child restarts; compare counter differences over a known interval rather than unrelated totals.
4. Read memory and eviction figures correctly
Open Storage after starting the fixture. Read allocated storage, limit, cached objects and evictions together.
These figures belong to the dedicated test instance. They are not per-domain disk usage.
The 32 MiB cache allocation is not a cap on total process memory. Process RSS is shown separately and includes more than cached response bodies. Leave room for the operating system, PHP workers, database, webserver and Varnish overhead when planning a later deployment. Varnish's storage documentation explains the additional allocations and allocator overhead; choosing a cache size equal to all free RAM is not a sizing method.
A growing eviction counter means objects have been evicted to make room. Record the increase during a representative workload. If useful frequently requested objects are evicted before reuse, capacity or the cached object mix deserves investigation. A single nonzero lifetime counter is not proof that the cache is too small. If objects expire before being reused, simply increasing capacity may not help.
5. Balance freshness with cache lifetime
TTL is the period a cached object can normally remain fresh. A longer value can reduce origin fetches but can also keep old public content visible longer unless it is invalidated. Determine how quickly a changed article, price, availability or announcement must appear before choosing a policy.
In this preview, successful explicitly public responses need a positive lifetime and are capped at 60 seconds. The addon does not give you a field to increase it. Test a changed public response with the exact-URL purge control and confirm that the next request gets the new content. A full-site purge and automatic WordPress invalidation are not implemented. Do not promise immediate updates across a whole site from a single-path purge.
6. Understand grace before requesting it
Varnish supports grace: eligible stale content can be served for an additional period while a fresh version is fetched. Keep has a different purpose: retaining an object for conditional revalidation. These are content-freshness choices, not universal speed switches. This addon currently sets grace to zero; it does not expose or validate a production stale-content policy. Consider such a feature only after its behavior and acceptable staleness have been tested for the application.
7. Tune the origin when misses are slow
If direct and MISS requests are slow while HIT is fast, investigate the work still required at the origin. Correlate the same time window with PHP slow requests, database slow queries, CPU, available RAM, swap activity and storage I/O. A Varnish HIT avoids that work for an eligible cached response; it does not repair slow authenticated pages or unsafe application queries.
Do not apply a universal PHP worker count or database buffer size from this guide. Measure the application's worker memory, database working set and server capacity first. Make one change at a time and compare the same workload, including errors. If direct requests are already fast, cold-cache overhead may exceed any benefit for a rarely reused URL.
8. Use errors and logs to choose the next action
- 4xx: check the requested path, access restrictions and application response. Do not disable private-page rules to hide an authorization error.
- 5xx: check the origin and relevant web/PHP error logs, then correlate with addon Activity. The addon Error Logs tab is a sample, not the full server log.
- Online - fallback / Needs attention: disable fixture caching, verify direct routing, then investigate the cache service. Availability and active caching are separate checks.
- Template did not save: read the validation message, correct unsupported path syntax, then apply and refresh. Do not assume a failed save changed the active policy.
9. Re-test privacy after each policy change
Check anonymous public pages, logged-in pages, two independent test users, cart/account/checkout pages, APIs, query-string URLs and responses that set cookies. Use disposable sessions and never publish their headers. Our existing fixture checks prove synthetic bypass behavior; real WordPress/WooCommerce and Laravel session isolation remain release gates. Template names alone are not proof of compatibility.
10. Keep a small change record
Code:
Date and component versions:
Test scope and application:
One setting changed:
Direct / cold MISS / warm HIT:
Requests, concurrency, errors, mean and p95:
HIT/MISS/BYPASS counts and interval:
Objects, allocation, eviction increase and RSS:
Privacy and content-update checks:
Rollback result:Retain the change only when it improves the intended workload without correctness or availability regressions. Stop the isolated test website after the exercise. Public deployment also needs a supported engine, tested installer, real-site routing and recovery; this preview is not that release.
References: Varnish storage backends; grace and keep.
Original AdminsForum lab screenshot. Copyright AdminsForum | adminsforum.com.