Fastly’s Segmented Caching feature allows you to cache files of any size. Segmented Caching works by breaking files into smaller segments in Fastly’s cache then recombining or splitting these files to respond to arbitrary size byte-range requests from clients. Once enabled, Segmented Caching improves performance for range requests and allows Fastly to efficiently cache files of any size.
WARNING: Fastly recommends enabling Segmented Caching on services that will be serving large files. Without Segmented Caching enabled, the file size limits for your account depend on when you become a Fastly customer:
- If you created your account on or after June 17, 2020 and haven't enabled Segmented Caching, your Fastly services have a maximum file size of 20 MB.
- If you created your account prior to June 17, 2020 and haven't enabled Segmented Caching, your Fastly services have a maximum file size of 2 GB without Streaming Miss or 5 GB with Streaming Miss.
How Segmented Caching works
When an end user makes a range request for a file with Segmented Caching enabled and a cache miss occurs (that is, at least part of the range is not cached), Fastly will make the appropriate range requests back to origin. Segmented Caching will then ensure only the specific portions of the file that have been requested by the end user (along with rounding based on object size) will be cached rather than the entire file. Partial cache hits will result in having the cached portion served from cache and the missing pieces fetched from origin. (Requests for an entire file would be treated as a byte range request from 0 to end of file.)
Once Fastly has all of the objects necessary to respond to an end user’s request, the Segmented Caching feature will assemble the response by concatenating or pulling portions of objects. The requests back to origin, also called “inner requests,” will have a true
value for segmented_caching.is_inner_req
and requests from end users, also called “outer requests,” will have a true
value for segmented_caching.is_outer_req
. If a request is made for an object without segmented caching enabled, both variables will have a FALSE value.
NOTE: The feature will only go back to origin for missing objects needed to handle the end-client’s byte range request. Cache hits will occur based on having that portion of file in cache even if the end user’s range exact request is unique.
Limitations and considerations
This feature has the following limitations and considerations you should take into account:
- Segmented Caching is not compatible with object compression and ESI. To use either of these features, you must ensure Segmented Caching is disabled.
- HTTP chunked transfer encoding between Fastly and origin isn't supported. Your origin server must frame responses to range requests with the
Content-Length
header. - HTTP headers
If-Modified-Since
andIf-None-Match
are not supported. Fastly only returns HTTP 200 OK and HTTP 206 Partial Content success status response codes. - URL purges must be authenticated. Segmented caching allows you to purge all range objects for the file by URL purge, but authentication for URL purge needs to be enabled due to its underlying implementation. Make sure you’ve provided an authorization token for URL purges as described in our purging documentation.
- Segmented Caching cannot be enabled based on file size. You must explicitly enable Segmented Caching using a conditional statement in your VCL (e.g., based on file extension or path). Our instructions below contain an example of how to enable the Segmented Caching feature based on extension.
- Files cached prior to enabling Segmented Caching are not used. If you are enabling Segmented Caching on an existing service, whole files already in cache are ignored and Varnish will go back to origin to build range request objects. You can choose to purge these or ignore them to be aged out of cache.
- Your cache hit ratio (CHR) will appear lower than it actually is because only outer requests are used in the calculation. For example, if there is a request for the first 100 MB of a file but Fastly only has 99 MB of 100 MB in cache, the entire request will be counted as a miss in the CHR stat. In practice, only 1 MB had to be fetched from origin and you experienced 99% origin offload.
Enabling Segmented Caching
Use the following steps to enable Segmented Caching.
-
Determine which files should use Segmented Caching.
TIP: We recommend focusing on a set of file extensions or a well-defined URL structure that distinguishes the files.
- From the service menu, select the appropriate service.
- Click the Edit configuration button and then select Clone active. The Domains page appears.
- Click the VCL Snippets link. The VCL Snippets page appears.
- Click the Create your first VCL snippet button. The Create a VCL snippet page appears.
- In the Name field, type an appropriate name (e.g.,
Enable segmented caching
). - From the Type (placement of the snippets) controls, select within subroutine.
- From the Select subroutine menu, select recv (vcl_recv).
-
In the VCL field, add a VCL snippet that sets the
req.enable_segmented_caching
VCL variable totrue
invcl_recv
. For example, to ensure proper caching of the large files you've identified that contain MPEG-2-compressed video data, you could add this VCL snippet in vcl_recv:1 2 3 4
# my custom enabled Segmented Caching code if (req.url.ext == "ts") { set req.enable_segmented_caching = true; }
This snippet tells Fastly to look for requests for files with the
ts
extension and then enable Segmented Caching for those files. - Click Create to create the snippet.
- Click the Activate button to deploy your configuration changes.