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:
- Enable Cloud CDN for one or more origins.
- Go to the Project Labels page in the Google Cloud Platform Console.
Go to the Project Labels page
- Add the
cloud-cdn-large-object-caching-betalabel to the project that contains your Cloud CDN origins. To do that, click Add label, enter
cloud-cdn-large-object-caching-betain the Key field, and click Save.
- 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
- It has a
- It has an
ETagheader with a strong validator and/or a
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
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.
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.