Documentation VIP Go Caching on VIP Go

Caching on VIP Go

Overview #

VIP Go employs several strategic layers of caching to achieve the highest possible performance while ensuring the site content is always up-to-date.

Much like WordPress.com VIP, Go’s caching can be divided into three main layers:

  • Page Cache
  • Object Cache
  • Query Cache

↑ Top ↑

Page Cache #

The first level of caching each request encounters is the Page Cache, powered by Varnish. On Go, this is a copy of the full page response that was generated by your site, and is served from our global network of edge locations (usually from memory). Often, this means that the majority of your site’s traffic can be served directly from the edge location closest to your visitors, without ever hitting a line of PHP, which means low-latency and very high performance.

Unchanged pages will remain in the edge cache for up to 30 minutes – but changes to the site content will automatically notify the edge caches of the new data and trigger a refresh, which means the site content is never stale. The list of flushed urls can be modified with the `wpcom_vip_cache_purge_urls` filter.

VIP Go also provides the means for Site Administrators to manually clear the edge caches as needed, by visiting the main WP Dashboard (/wp-admin) and clicking the ‘Purge Cache’ button.

Logged in visitors, commenters, requests to modify state (such as POST requests), and requests for pages that are not actively cached at the edge will be routed to the site’s origin servers, which are running your site’s code and database.

We have documentation on controlling the VIP Go page cache.

↑ Top ↑

Object Cache #

Each Go site is provisioned with its own silo’d Memcache cluster for caching application level data, and the WordPress object cache (and transients) are automatically configured to use these instances. This means that many common operations will automatically be routed to memory instead of the database.

This also means that any application data can be easily cached in memory, to reduce the cost of repetitive or expensive computations. The best candidates for caching are any data that will take longer to calculate (such as expensive database queries) than it takes to grab the data from the cache, keeping in mind each cache request is processed over the local network, so a very large number of cache lookups/sets can add processing time to the page. Cache entries must be kept under 1MB in size.

For more information on using object caching in WordPress, see WP Object Cache.

↑ Top ↑

Query Cache #

Working hard behind the scenes to keep your VIP site happy is the Query Cache. This layer provides light-weight and transparent in-memory caching of many database queries, such as post lookups, which reduces the overall load on the database and results in a faster, more-scalable site.

All application code that uses the WP_Query API will automatically benefit from this caching layer.

Most write operations will flush this cache (such as post updates and comments) to ensure fresh data, so it’s important to cache expensive queries in a more persistent way, using object caching.

Documentation is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.