How to use this cache TTL guide
Enter the TTL you plan to set along with the number of cache keys, the request rate and the observed span, and the tool reports how many requests reach the origin and how long a stale response can be served. Add the staleness you can accept and it judges whether the TTL fits, and an origin update interval shows how many updates a single TTL buries.
How the numbers are derived
Origin requests are keys times the span divided by the TTL, rounded up, which assumes each key is refilled once per TTL and so sits close to an upper bound. The stale bound equals the TTL and averages half of it. There is no authoritative recommended TTL, so no value is suggested here.
Limits and cautions
The real hit rate depends on how often each key is requested and is not predicted. Adding stale-while-revalidate extends the stale bound by that amount, and assembling those directives belongs to the Cache-Control generator.
Frequently asked questions
There is no authoritative recommended value. A stale response can go out for up to the TTL after content changes, so decide the staleness you can accept first and pick within it.
If each key is refilled once per TTL, origin requests fall in inverse proportion to the TTL. The table compares multiples of the TTL you entered.
No. That depends on the access distribution and is not predicted here. Hit rate and cost savings belong to the CDN cache hit rate tool.