Updated 24 October 2026 | Varnish Cache by Adminforum 0.6.0-lab | Verified scope: one audited WordPress/Nginx website.
On 24 October 2026, the current managed WordPress/Nginx lab integration passed 38 application checks, plus 3 installation-safeguard checks. The current-source backend suite passed 161 tests; the frontend suite passed 38 checks. These are separate suites, not counts of independent websites or server modes.
The website was left added and enabled after testing. The disposable application fixtures were moved to WordPress Trash, and the other Nginx/Apache website configuration files were unchanged. Postfix and Dovecot remained active; this checks service state, not end-to-end mail delivery.
Environment
Website: blog.adminslab.com — isolated test site
Operating system: Ubuntu 22.04 VPS, 2 CPU cores, approximately 4 GiB RAM
aaPanel: 8.0.7
Assigned website server: Nginx 1.30.6
PHP: 8.5.12
WordPress: 7.1.3
Varnish: 9.1.0
Cache policy: Public homepage/posts, up to 30 seconds; 32 MiB capacity
WooCommerce: Not installed
Before and after response times
Native WordPress, cache disabled
Requests: 30
Expected response: DIRECT
Median: 142.298 ms
p95: 171.835 ms
Varnish, warmed public post
Requests: 30
Expected response: HIT
Median: 7.772 ms
p95: 12.075 ms
Varnish, exact post purged before each request
Requests: 10
Expected response: MISS
Median: 132.968 ms
p95: 156.915 ms
Warm-cache median complete response time was 94.5% lower than the direct median in this sample. This is a local lab comparison, not a promise of the same reduction for visitors.
Measurement method
The test requested the same newly published public WordPress post through verified HTTPS on the VPS's loopback connection using the real hostname. Every measured request opened a new connection and read the complete response; timings include TLS setup. Requests were sequential. The p95 uses the nearest-rank method.
The direct phase disabled the managed route and verified the exact original configuration. The warm phase restored caching and warmed the public post before measuring. The cold phase purged that exact path before each request. Each measured response had to return HTTP 200 with the expected DIRECT, HIT or MISS marker. Dashboard live polling was paused during the measurements.
This is not an internet-latency, browser-rendering, throughput, sustained-load or high-concurrency benchmark. Test order and normal server variation can affect results. The slightly lower cold-MISS median than direct does not establish that misses are faster; both execute the origin application and their small difference needs broader controlled measurements.
Application and privacy results
Draft publication: Anonymous draft request was unavailable; published post returned MISS then HIT.
Content update: A real WordPress post update invalidated the old cached content automatically.
Comment edit: Editing a stored approved comment invalidated the post cache.
Public response headers: Cached public post did not carry Set-Cookie.
Two real accounts: Both existing test readers logged in and received their own uncached profile pages.
Concurrent identity isolation: 12 interleaved profile requests across two users and four workers retained the correct user identity. This is a small functional check, not a load benchmark.
Nonces: The two profile pages had distinct nonces.
Exclusions: Cookies, Authorization, search, REST API, admin, POST, cart/account/checkout paths bypassed.
Private content: A new private post was not exposed anonymously or served as a HIT.
Purge protection: Public PURGE/BAN were rejected; an invalid private purge key was rejected.
Trash invalidation: Trashing the disposable public post removed its cached public content.
Coexistence: Other checked Nginx/Apache vhost files stayed byte-identical; Nginx validation passed and mail services remained active.
Final state: The managed cache remained enabled and verified active.
The cart/account/checkout checks exercised excluded paths on a site without WooCommerce. They do not establish shopping-cart, payment or store-plugin compatibility.
Installation safeguards
The installed control-file validation completed without changing the active public website route. Attempting uninstall while the native cache was configured returned the expected refusal. The plugin files and native route were preserved.
This tests a guard, not a successful clean uninstall/reinstall. The current build still depends on the prepared lab runtime.
Earlier on the same day, a separate 29-check managed lifecycle run passed exact direct-route restoration, re-enable, stopped-cache fallback and recovery. Those earlier lifecycle results are distinct from the new 38-check application run; they should not be presented as newly retested behavior where it was not repeated.
What remains before public beta
WordPress on this audited Nginx lab site: Application and managed lifecycle evidence available
Other Nginx sites / portable site onboarding: Not validated; current target is restricted in code
Native Apache, OpenLiteSpeed, Nginx + Apache, Nginx + OpenLiteSpeed: Adapters/live compatibility not established
Mixed-engine cached websites: Not established
WooCommerce cart/session/payment journey: Not tested; WooCommerce absent
Browser editor and public comment submission: Not exercised by this API-based application run
Native access/error log views and persistent traffic history: Not connected; live chart is a browser-session buffer
Clean-server install, upgrade, successful uninstall/reinstall: Not established by this run
Reboot, certificate renewal, native engine/PHP switching: Not exercised
Sustained traffic and resource-pressure testing: Not performed
Release decision: keep this build in the closed lab programme. The results support further development and targeted testing; they do not approve a general aaPanel beta release.
Evidence and reproduction
The companion sanitized results summary (the measured values are reproduced in this report) records the measured values, suite counts and limits. The reproducible test source and private raw timing evidence are retained with our lab records. The test is fixed to this lab; it is not a portable installer.
Private detailed results, raw timing samples and any diagnostics are retained on the lab under the operator's test-evidence directory. Credentials, cookies, nonces and private PHP errors are not included in this guide bundle.
Official architecture reference: aaPanel Multi-WebServer Hosting. This describes aaPanel's server choices, not compatibility certification for our addon.
Original AdminsForum lab work. Copyright AdminsForum | adminsforum.com.
Guide series: Installation | WordPress configuration | Measured results
Historical attachments dated 20 October below belong to the older synthetic fixture run. They are retained as earlier evidence and are not the raw samples for the 24 October WordPress measurements above.
On 24 October 2026, the current managed WordPress/Nginx lab integration passed 38 application checks, plus 3 installation-safeguard checks. The current-source backend suite passed 161 tests; the frontend suite passed 38 checks. These are separate suites, not counts of independent websites or server modes.
The website was left added and enabled after testing. The disposable application fixtures were moved to WordPress Trash, and the other Nginx/Apache website configuration files were unchanged. Postfix and Dovecot remained active; this checks service state, not end-to-end mail delivery.
Environment
Website: blog.adminslab.com — isolated test site
Operating system: Ubuntu 22.04 VPS, 2 CPU cores, approximately 4 GiB RAM
aaPanel: 8.0.7
Assigned website server: Nginx 1.30.6
PHP: 8.5.12
WordPress: 7.1.3
Varnish: 9.1.0
Cache policy: Public homepage/posts, up to 30 seconds; 32 MiB capacity
WooCommerce: Not installed
Before and after response times
Code:
Local verified HTTPS Requests Median ms p95 ms
Direct WordPress 30 142.298 171.835
Warm Varnish HIT 30 7.772 12.075
Cold Varnish MISS 10 132.968 156.915Native WordPress, cache disabled
Requests: 30
Expected response: DIRECT
Median: 142.298 ms
p95: 171.835 ms
Varnish, warmed public post
Requests: 30
Expected response: HIT
Median: 7.772 ms
p95: 12.075 ms
Varnish, exact post purged before each request
Requests: 10
Expected response: MISS
Median: 132.968 ms
p95: 156.915 ms
Warm-cache median complete response time was 94.5% lower than the direct median in this sample. This is a local lab comparison, not a promise of the same reduction for visitors.
Measurement method
The test requested the same newly published public WordPress post through verified HTTPS on the VPS's loopback connection using the real hostname. Every measured request opened a new connection and read the complete response; timings include TLS setup. Requests were sequential. The p95 uses the nearest-rank method.
The direct phase disabled the managed route and verified the exact original configuration. The warm phase restored caching and warmed the public post before measuring. The cold phase purged that exact path before each request. Each measured response had to return HTTP 200 with the expected DIRECT, HIT or MISS marker. Dashboard live polling was paused during the measurements.
This is not an internet-latency, browser-rendering, throughput, sustained-load or high-concurrency benchmark. Test order and normal server variation can affect results. The slightly lower cold-MISS median than direct does not establish that misses are faster; both execute the origin application and their small difference needs broader controlled measurements.
Application and privacy results
Draft publication: Anonymous draft request was unavailable; published post returned MISS then HIT.
Content update: A real WordPress post update invalidated the old cached content automatically.
Comment edit: Editing a stored approved comment invalidated the post cache.
Public response headers: Cached public post did not carry Set-Cookie.
Two real accounts: Both existing test readers logged in and received their own uncached profile pages.
Concurrent identity isolation: 12 interleaved profile requests across two users and four workers retained the correct user identity. This is a small functional check, not a load benchmark.
Nonces: The two profile pages had distinct nonces.
Exclusions: Cookies, Authorization, search, REST API, admin, POST, cart/account/checkout paths bypassed.
Private content: A new private post was not exposed anonymously or served as a HIT.
Purge protection: Public PURGE/BAN were rejected; an invalid private purge key was rejected.
Trash invalidation: Trashing the disposable public post removed its cached public content.
Coexistence: Other checked Nginx/Apache vhost files stayed byte-identical; Nginx validation passed and mail services remained active.
Final state: The managed cache remained enabled and verified active.
The cart/account/checkout checks exercised excluded paths on a site without WooCommerce. They do not establish shopping-cart, payment or store-plugin compatibility.
Installation safeguards
The installed control-file validation completed without changing the active public website route. Attempting uninstall while the native cache was configured returned the expected refusal. The plugin files and native route were preserved.
This tests a guard, not a successful clean uninstall/reinstall. The current build still depends on the prepared lab runtime.
Earlier on the same day, a separate 29-check managed lifecycle run passed exact direct-route restoration, re-enable, stopped-cache fallback and recovery. Those earlier lifecycle results are distinct from the new 38-check application run; they should not be presented as newly retested behavior where it was not repeated.
What remains before public beta
WordPress on this audited Nginx lab site: Application and managed lifecycle evidence available
Other Nginx sites / portable site onboarding: Not validated; current target is restricted in code
Native Apache, OpenLiteSpeed, Nginx + Apache, Nginx + OpenLiteSpeed: Adapters/live compatibility not established
Mixed-engine cached websites: Not established
WooCommerce cart/session/payment journey: Not tested; WooCommerce absent
Browser editor and public comment submission: Not exercised by this API-based application run
Native access/error log views and persistent traffic history: Not connected; live chart is a browser-session buffer
Clean-server install, upgrade, successful uninstall/reinstall: Not established by this run
Reboot, certificate renewal, native engine/PHP switching: Not exercised
Sustained traffic and resource-pressure testing: Not performed
Release decision: keep this build in the closed lab programme. The results support further development and targeted testing; they do not approve a general aaPanel beta release.
Evidence and reproduction
The companion sanitized results summary (the measured values are reproduced in this report) records the measured values, suite counts and limits. The reproducible test source and private raw timing evidence are retained with our lab records. The test is fixed to this lab; it is not a portable installer.
Private detailed results, raw timing samples and any diagnostics are retained on the lab under the operator's test-evidence directory. Credentials, cookies, nonces and private PHP errors are not included in this guide bundle.
Official architecture reference: aaPanel Multi-WebServer Hosting. This describes aaPanel's server choices, not compatibility certification for our addon.
Original AdminsForum lab work. Copyright AdminsForum | adminsforum.com.
Guide series: Installation | WordPress configuration | Measured results
Historical attachments dated 20 October below belong to the older synthetic fixture run. They are retained as earlier evidence and are not the raw samples for the 24 October WordPress measurements above.
