Permanent Cache

Benefits

The Bytescale CDN's permanent cache:

How it works

Bytescale's permanent cache is a configurable cache that permanently stores processed files for fast subsequent responses.

By default, files that take longer than 500 milliseconds to process will be permanently cached.

When permanent caching is enabled:

Please note:

• Permanent caching adds ~100ms of latency to the initial response.

• This occurs once per URL: when both the permanent cache and edge cache are missed.

Performance

Example download performance of a 4000×2667 JPEG with image processing applied:

The Bytescale CDN further reduces latency by routing edge cache misses to a master edge cache node. This additional optimization reduces edge cache misses by keeping traffic within the edge network where possible: requests are only forwarded to the central permanent cache when both the regional edge cache nodes and the master edge cache node don't have a copy of the requested file.

Using these techniques, Bytescale is able to ensure there is only one file processing request per URL.

Measuring performance

Time to First Byte (TTFB) is a key metric for measuring the performance of a file processing solution.

TTFB measures the end-to-end latency of a request, and includes DNS resolution, TLS handshakes, and file processing.

Measuring cache hits

The Bytescale CDN includes the following HTTP response headers to help users identify cache hits and misses:

HTTP/2 200
...
x-cache: Hit
x-cache-perma: Miss
x-cpu-on-cache-miss: 971
...

• x-cache: header values containing Hit indicate the response was served from the edge cache, else:

• x-cache-perma: header values containing Hit indicate the response was served from the permanent cache, else:

• The cache was missed (aka a "full cache miss").

If both headers contain Miss then the response is considered a "full cache miss", else it's considered a "cache hit".

File processing only occurs on a "full cache miss":

• The x-cpu-on-cache-miss header is present on all "full cache miss" responses and on some "cache hit" responses. The header indicates the processing time (in milliseconds) that was spent on the last "full cache miss". When this header is returned for "cache hit" responses, it should be ignored by clients, as no file processing will have occurred; the header is an echo from the last "full cache miss".

• The x-cpu-on-cache-miss-adjusted may also be present, and indicates the amount of CPU time that was consumed from your monthly CPU quota on the full cache miss. This value may be different from the x-cpu-on-cache-miss header value (which indicates the wall clock processing time). This header will only be present on certain transformation types, like video and audio transformations. If this header is not present, then the x-cpu-on-cache-miss header indicates the amount of time that was consumed from your monthly CPU quota. Similarly to x-cpu-on-cache-miss (above) this header should be ignored by clients for "cache hit" responses.

Cache resets

To reset your edge cache and permanent cache, click "Reset Cache" on the cache settings page in the Bytescale Dashboard.

Cache configuration

Bytescale's permanent cache can be configured via the URL and also via your account's settings (to control default cache behavior).

Account settings

Your account's default cache behavior is configured via the Bytescale Dashboard and determines:

• Edge cache TTL duration.

  • The maximum amount of time a file will stay in a regional edge cache node.

  • Default: 1 year.

• Permanent cache behavior.

  • The strategy used to determine when to permanently cache a processed file.

  • Default: permanently cache files that take > 500 milliseconds to process.

Querystring parameters

You can override your account's default cache behavior via the URL for each request:

• ?v=123

  • Forces an edge cache miss and permanent cache miss each time 123 is changed to a unique value.

• ?cache=false

  • Forces an edge cache miss and permanent cache miss on each request.

• ?cache_ttl=31536000

  • Specifies the maximum time to store the file in the edge cache.

• ?cache_perm=auto|false|true

  • Specifies whether to permanently cache the processed file.

  • Permanent caching adds ~100ms of latency to the initial request. This latency is incurred once per URL: when both the permanent cache and edge cache are missed (i.e. when the URL is first requested).

  • If auto is used, the file will be permanently cached if it takes > 500 milliseconds to process.