An experiment: what would Varnish full-page caching do for Aero Commerce, a Laravel-based ecommerce platform? On one rudimentary load test, peak throughput went from 21 requests a second without it to 3,350 with it.
What did the load test show?
One k6 run per configuration, 100 virtual users for about three minutes, against a demo store on a Hetzner CPX31 (4 vCPU, 8GB):
| Without Varnish | With Varnish | |
|---|---|---|
| Peak requests a second | 21 | 3,350 |
| p95 response time | 6,619 ms | 51 ms |
| Requests made | 3.3K | 588.6K |
| HTTP failures | 0 | 0 |
The README calls it an extremely rudimentary test, and it assumes a high cache hit rate. Real gains depend on how much of the traffic Varnish can serve.
How do I install aero-module-varnish?
The module is version 0.0.1, not on Packagist, and installs from the Git repository:
composer config repositories.samjuk-aero-module-varnish vcs [email protected]:SamJUK/aero-module-varnish.git
composer require samjuk/aero-module-varnish:@devHow does it cache Aero pages?
It marks storefront pages as cacheable, keeps per-user data out of them, and purges by tag when something changes.
The module swaps Aero’s no-cache middleware for one that marks storefront pages cacheable for a day (max-age=86400, public, s-maxage=86400) and tags them by page type: CMS pages, categories (plus every product in them), products and search. Anything under /admin, /account, /cart, /checkout or /personaldata is never cached.
The cache varies on a cookie holding a hash of the login state and customer group. Per-user data, such as the cart count and CSRF token, comes from a small JSON endpoint injected into the page head, so cached pages stay shared. Thirteen Aero events, from product saves to cart changes and search index rebuilds, trigger queued purges by tag.
An admin page generates the VCL from a template with the backend host, port and purge ACL filled in, and can purge everything, or by tag, entity or URI. There is also a php artisan varnish:purge command.