As a CMS, WordPress is heavily dependent on its database, and database efficiency is crucial to scaling( capability to handle increased/growing workload ) WordPress. If requests to your website generates a large number of database queries, your database servers resource can become overwhelmed. This will reduce your site’s performance and uptime.
To avoid multiple database queries , WordPress stores its data in object cache as a key-value pairs in
$wp_object_cache variable, in cache.php.
cache.php file has WP_Object_Cache class, which is used for caching data. We should not use the class directly but should rather use a set of wp_cache functions which allow you to store key-value pairs in memory and you can also set an expiration time for keys.
In WordPress, the object cache functionality provided by WP_Object_Cache, and the Transient API are great solutions for improving performance on long-running queries, complex functions, or similar.
On a regular WordPress install, the difference between transients and the object cache is that transients are persistent and would write to the options table, while the object cache only persists for the particular page load.
By default, the data stored in Object Cache stays in the memory only for a duration of an HTTP request( single page load ) . Once the request is served the data is no longer available. So WordPress Object cache is non-persistent by default.
To make the object cache persistent across all HTTP requests or to override wordpress default caching, you need to create a file called object-cache.php in wp-content which needs to override all the functions of WordPress Object Cache.This overwritten functions can store the key-value pairs in any persistent caching storage system such as Redis, Memcached etc( which are open source memory caching tools )
There are lots of popular plugins like
WP Redis and
Memcached Object Cache which make the object cache persistent. They store key-value pairs in Redis and Memchached respectively.
On environments with a persistent caching mechanism (i.e. Memcache, Redis, or similar) enabled, the transient functions become wrappers for the normal WP_Object_Cache functions. The objects are identically stored in the object cache and will be available across page loads.
Every WordPress API makes a copy of the data in cache, during its CRUD process.
get_option call is made
- WordPress runs wp_load_alloptions()
- If your option is autoloaded, wp_load_alloptions() returns an array of autoloaded options
- If your option is not autoloaded, WordPress returns the value of that option from the cache, if cache is not present then it returns it from the database and set a cache value for it.
- If the option name was invalid, WordPress stores that option name in ‘notoptions’ cached array, and will check the ‘notoptions’ array first if subsequent calls are made to the same non existing option name.
So options are loaded into the object cache so when you request an option there’s a 99% chance that request will never hit the database.