Skip to content

Object cache

Each WordPress environment is provisioned with its own siloed Memcached cluster for persistently caching application-level data. The WordPress object cache (and transients) is automatically configured to use these instances. This enables common operations to be automatically 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 retrieve the data from the cache. Keep in mind that each object cache request is processed over a local network, so many cache lookups/sets can add processing time to the page.


Because transients are stored in the object cache on VIP, any plugins or custom code that query the database for transients will fail. Similarly, the wp transient list WP-CLI command will not work as expected because it performs a database query. The WP-CLI command will return a warning.

As an alternative, individual transients can be managed with the wp transient WP-CLI command if the key for the transient is known.

wp_cache functions

Memcached employs a Least Recently Used (LRU) algorithm. The LRU determines which object(s)—if any—should be evicted from the object cache when a new object is being added and the object cache is full.

When adding, setting, or replacing objects with wp_cache functions, an integer representing the TTL in seconds can be passed as the $expire parameter. The default value of $expire is 0, which is no expiration. When an object has no expiration, it will only be evicted by the LRU algorithm unless it is specifically deleted or updated by a wp_cache function.

For more information about object caching in WordPress, review WP Cache Functions in’s Developer Reference.

Last updated: April 30, 2024

Relevant to

  • WordPress