HomeServerBlog edge cache tool
Reverse Proxy Cache Calculator
Estimate origin RPS offload, resident disk cache size, origin bandwidth saved, and metadata RAM pressure for NGINX, Varnish, Traefik plugin caches, API gateways, image caches, package mirrors, and public-share front ends.
Calculation breakdown
Cache capacity verdict
The meter tracks calculated cache storage against the disk cache capacity.
| Cache layer | Best fit | Primary limit | Planning note |
|---|---|---|---|
| NGINX proxy_cache | Static assets, public pages, thumbnails | keys_zone RAM and disk manager scans | Use proxy_cache_lock for thundering herd control. |
| Varnish cache | WordPress, CMS pages, reverse proxy front ends | RAM storage or malloc-backed object store | Hit ratio depends on cookies and vary headers. |
| Traefik plugin cache | Container labs and smaller service fronts | Plugin storage backend and key rules | Keep cache rules simple and service-specific. |
| API gateway cache | Short JSON responses, rate-limited origins | TTL correctness and invalidation | Cache only responses that are safe per user scope. |
| Mirror cache | Packages, CI artifacts, game updates | Disk capacity and egress link speed | Long TTL works well when objects are immutable. |
| Output | Formula used | What increases it | What reduces it |
|---|---|---|---|
| Origin offload RPS | Origin RPS x cacheable % x hit ratio, plus SWR collapse | Higher hit ratio, more cacheable routes, longer TTL | Auth bypass, cookies, low TTL, many one-off keys |
| Storage needed | Resident objects x average object KB x overhead buffer | More unique keys, bigger objects, longer TTL, stale window | Normalized keys, compression, cache max size policy |
| Bandwidth saved | Offloaded RPS x average object KB x 8 / 1024 | Large objects and high hit rates | Small API bodies and partial cacheability |
| Metadata RAM | Resident objects x bytes per object x overhead buffer | High cardinality, vary headers, per-user cache keys | Key normalization and shorter retention windows |
| Preset | Cache personality | Typical object size | First tuning knob |
|---|---|---|---|
| NGINX Static Cache | CSS, JS, public pages, font files | 32 to 128 KB | Increase keys_zone before disk looks full. |
| Varnish WordPress Front | HTML pages and static theme assets | 40 to 180 KB | Fix cookie bypass rules before adding hardware. |
| API Response Cache | Small JSON with short TTL and SWR | 4 to 32 KB | Use route-specific TTL and vary only when required. |
| Image Thumbnail Cache | Many image variants from galleries | 80 to 400 KB | Watch disk writes and resize variants. |
| Package Mirror | Large immutable archives and indexes | 512 KB to many MB | Prefer disk capacity and network throughput. |
| Nextcloud Public Shares | Large shared files with bursty readers | 256 KB to many MB | Keep private and authenticated routes uncached. |
| Disk used | Status | Likely behavior | Practical response |
|---|---|---|---|
| Under 60% | Comfortable | Cache manager has room for churn and stale objects | Focus on hit ratio and origin logs. |
| 60% to 85% | Watch | Eviction can begin during bursts or deploy spikes | Add disk, trim TTL, or normalize cache keys. |
| 85% to 100% | Tight | Hot objects may churn and hit ratio can fall | Reduce variants and reserve space for managers. |
| Over 100% | Undersized | Cache will evict before the TTL model is achieved | Increase cache path size or lower resident object count. |
Reverse proxies are caches that help you scale apps; if the origin is a bottleneck then you’ll need to size the reverse proxy cache with the origin protection in mind but also disk space and memory overhead required. With the calculator, you just plug in your traffic patterns and it does the rest of math for you so you don’t have to guess how many megabytes of RAM it’s going to take up for its metadata index.
The first thing everyone looks at are hit ratios or some other measure of raw throughput. This doesn’t tell you anything about how “big” the data is. If you’re serving tiny JSON API responses with a high hit ratio, that won’t save much bandwidth. Your app will still be protected but you haven’t unloaded the network link. On the flip side, low-hit-rate but large items like software packages and image thumbnails can drasticly reduce origin loads. This cuts down on traffic because each request has a hefty payload. You’re caching weight. The tool breaks out request offload versus bandwidth savings so you can see what matters for your own workload profile.
How to Plan Your Cache Size
The other important variable is metadata overhead. Before any object even hits the disk, it has to have an index entry, a lock, and take some space in RAM as its header. Most of your objects might be generated from unique keys with short TTLs. This is common in API gateways where query parameters generate thousands of different cache key. If this happens, your memory will soon be full long before your storage drive fills up. The calculator makes you factor in bytes-per-object so that you don’t make the all-too-common mistake of buying huge disks but still running out of swap space on a humble machine. It makes abstract into something concrete that can fit within a real memory budget that you can set up.
A second wrinkle is time-to-live. Shorter TTL mean more churn. Good stuff gets flushed out of your cache and replaced with the exact same data five minutes later. Longer TTL solves that eviction issue at the cost of staleness. And that becomes particularly problematic when your origin content changes often and isn’t invalidated properley. That’s where stale-while-revalidate comes in. The proxy serves a slightly older copy until it fetches an updated copy behind the scenes. It collapses those large groups of simultaneous requests down to a single request on the origin. We include this as factor in our estimator. This shows you how much extra traffic smart revalidation locking offloads more than just raw storage capacity.
Real world scenarios are implemented as presets in the tool, and these profiles behaves very differently under the hood. The front-end of WordPress is not a mirror. The front end is dynamic content. It pollutes cookies and varies its headers which fragments your cache key space. This requires using more RAM for index and tuning bypass rules more aggressively. A package mirror likes a lot of cheap disk space and reads in sequence. It thrives based off unchangeable objects with long retention times. That’s not how the other one is. Knowing this lets you know when to spend money on faster NVMe disks and when you can just throw more memory at the system.
Caching ends up being an optimization exercise in costs, complexity, and freshness. Zero overhead is at the cost of infinite variety. It’s not about maximizing your hit ratio; it’s about improving how you distribute your resources for maximum efficiency. Quantify the bandwidth reduction, RAM pressure, and disk usage trade-off so you stop guessing and start engineering. Design buffer based off what your load actualy is instead of just the average, and your server remains snappy even when it’s under a burst. That’s what gives you an edge through resilience.
