Large Object Caching

The General Availability (GA) release of Google Cloud CDN can cache content up to 10 MB in size. The Cloud CDN Large Object Caching Beta increases that limit and improves support for partial responses.

Participating in the Beta program

If you'd like to participate in the Large Object Caching Beta program, please register your interest by performing the following steps:

  1. Enable Cloud CDN for one or more origins.
  2. Go to the Project Labels page in the Google Cloud Platform Console.
    Go to the Project Labels page
  3. Add the cloud-cdn-large-object-caching-beta label to the project that contains your Cloud CDN origins. To do that, click Add label, enter cloud-cdn-large-object-caching-beta in the Key field, and click Save.
  4. Submit the Beta signup form, making sure to specify the same project as in steps 1 and 3.

We'll contact you by email if you are selected to participate in the Large Object Caching Beta or we require additional information. Please note that it might take several days to process your Beta signup request.

Large object caching improvements

Before the Large Object Caching Beta, partial responses and responses with bodies larger than 10 MB were never cached by Cloud CDN. With the Large Object Caching Beta, Cloud CDN can now cache content that is up to 5 TB (5,497,558,138,880 bytes) in size.

The Large Object Caching Beta changes the way content is retrieved and stored:

  • Content that is larger than 1 MB (1,048,576 bytes) in size is retrieved and stored in cache as a sequence of byte ranges.
  • Content that is served as partial responses is also retrieved and stored in cache as a sequence of byte ranges.
  • Complete responses with bodies 1 MB in size or smaller are retrieved and stored as before.

Support for byte range requests

To benefit from the Large Object Caching Beta, your origin server must support byte range requests.

Google Cloud Storage supports byte range requests for most objects. However, Cloud Storage does not support byte range requests for objects with Content-Encoding: gzip metadata unless the client request includes an Accept-Encoding: gzip header. If you have Cloud Storage objects larger than 1 MB in size, make sure they do not have Content-Encoding: gzip metadata. Refer to Viewing and Editing Object Metadata for information on how to edit object metadata.

Popular web server software also supports byte range requests. Consult your web server software's documentation for details on how to enable support. For more information on byte range requests, refer to the HTTP specification.

A Cloud CDN cache can decline to store an otherwise cacheable response the first time it is requested for one of the following reasons:

  • The response body is incomplete, because the client requested only part of the content
  • The response body is larger than 1 MB in size

When this happens and the response would otherwise satisfy the normal Cloud CDN caching requirements, the cache records whether the origin server supports byte range requests for that cache key. A response that satisfies the following criteria indicates that the origin server supports byte range requests:

  • Its status code is 200 OK or 206 Partial Content
  • It has an Accept-Ranges: bytes header
  • It has a Content-Length and/or Content-Range header
  • It has an ETag header with a strong validator and/or a Last-Modified header

On a cache miss, the cache checks whether the origin server is known to support byte range requests. If byte range requests are known to be supported for the cache key, the cache will not forward the client request to the HTTP(S) load balancer. Instead, the cache will initiate its own byte range cache fill requests for the missing parts of the content. If your origin server returns the requested byte range in a 206 Partial Content response, the cache can store that range for future requests.

A cache will store a 206 Partial Content response only when received in response to a byte range request that the cache initiated. Because a cache won't initiate a byte range request unless it had previously recorded that the origin server supports byte range requests for that cache key, a given cache won't store content that's larger than 1 MB in size until the second time that content is accessed.

Requests initiated by Cloud CDN

When your origin server supports byte range requests, Cloud CDN can send multiple requests to your origin server in reaction to a single client request. As described below, Cloud CDN can initiate two types of requests: validation requests and byte range requests.

If the response that indicated your origin server supported byte range requests for a particular cache key has expired, Cloud CDN will initiate a validation request to confirm that the content hasn't changed and that your origin server still supports range requests for the content. If your origin server responds with a 304 Not Modified response, Cloud CDN will proceed to serve the content using byte ranges. Otherwise, Cloud CDN will forward your origin server's response to the client. You control expiration times using the Last-Modified and Expires response headers.

On a cache miss, Cloud CDN initiates cache fill requests for a set of byte ranges that overlap the client request. If some ranges of the content requested by the client are present in cache and others are not, Cloud CDN will serve whatever it can from cache and send byte range requests for only the missing ranges to your origin server.

Each byte range request initiated by Cloud CDN specifies a range that begins at an offset that's a multiple of 2,097,136 bytes. With the possible exception of the final range, each range is also 2,097,136 bytes in size; if the content isn't a multiple of that size, the final range will be smaller. The size and offsets used in byte range requests might change in the future.

As an example, consider a client request for bytes 1,000,000 through 3,999,999 of content that is not present in cache. In this example, Cloud CDN could initiate two GET requests, one for the first 2,097,136 bytes of the content and another for the second 2,097,136 bytes. This results in 4,194,272 bytes of cache fill even though the client requested only 3,000,000 bytes.

When you use a Cloud Storage bucket as your origin, each GET request is billed as a separate Class B operation. You are charged for all GET requests processed by Cloud Storage, including any requests initiated by Cloud CDN. When a response is served entirely from a Cloud CDN cache, no GET requests are sent to Cloud Storage, and you are not charged for any Cloud Storage operations.

When Cloud CDN initiates a validation request or byte range request, it does not include client-specific headers such as Cookie or User-Agent.

Stackdriver Logging

When Cloud CDN serves a client request by initiating validation requests and/or byte range requests, it omits the serverIp field from the Stackdriver Logging log entry for the client request. This is because Cloud CDN can send requests to multiple server IP addresses in reaction to a single client request.

Each request initiated by Cloud CDN will also create a Stackdriver Logging log entry. As noted in the Known Issues section, the log entries for requests initiated by Cloud CDN may have incomplete or incorrect information.

Known issues

  • Stackdriver Monitoring metrics and Cloud Console graphs omit validation requests and byte range requests initiated by Cloud CDN. Instead, these systems track only requests that Cloud CDN received from clients. We expect to resolve this prior to the GA release.

  • As a result of omitting requests initiated by Cloud CDN, Cloud Console and Stackdriver Monitoring report higher than actual cache hit ratios. A client request counted as a cache hit may still have caused Cloud CDN to send requests to one of your backends.

Was this page helpful? Let us know how we did:

Send feedback about...

Cloud CDN Documentation