What does “caching” mean?
When a request for a page on your site comes in, the page is sent to the server to be “compiled,” or generated based on the code that exists on that page. This in and of itself doesn’t cause much strain for the server, as it’s pretty easy to serve just one page. Now imagine the server is having to build multiple pages per second – suddenly that job becomes much harder!
Caching serves to help out with the heavy lifting the server does by storing a copied “snapshot” of each page request that comes into the server. When a page request comes to the server, it first asks whether the page is in cache. If not, it’s sent to the server to be built and then served, and on its way back it also stores a copy of that page within the caching layer. This way, the next time a request for that page comes in, it can be served from the caching layer, instead of having to be built like new from the server itself.
This lightens the workload of the server, which means it can handle way more traffic at once than it otherwise could. It also speeds up your site, because serving a page from cache is much faster than building it like new every single time. This is the type of caching that our WP Engine Page Cache™ uses to help improve your site’s performance. Read more about this type of caching here.
So what is Object Caching then?
Object Caching is a different type of caching – instead of caching pages and resources like images, or stylesheets, it caches repeated query results.
Queries are requests for data from the database on a site.
Similar to regular page requests, queries can easily “pile up” and cause slowness on sites if too many are run at a time. An example of a query would be redirects configured through a WordPress plugin on your site. Any time a page of your website is loaded, WordPress must load the list of redirects by making a database query.
Object Caching takes queries that are run on the site and stores the results of those queries in its Object Caching layer. This helps speed up the operation so your server doesn’t have to generate a new result every time, and also helps your server’s health, meaning it will spend less time and energy searching for the same thing repeatedly.
In the graphic above, a query request is received by the site. The server first checks to see if it has any results for this query in the Object Caching layer. If it doesn’t, it sends the query to be run in the database. On the way back to serve the results of that query, it stores a copy of the results in the Object Caching layer so the server doesn’t have to reach back to the database the next time the query is run.
What if I want a query to show new content?
The Object Caching layer isn’t cleared out at a specific time interval. Instead, it purges specific query results from its cache once its allotted storage space is used up. It then uses an algorithm to figure out which query it’s storing is the “least recently used,” to decide which query would be best to purge from its cache.
It’s possible that you may have added content to your site, and specifically want queries to reflect that new content. In this case, you’d want to use the “Purge all Caches” button within your WordPress Admin Dashboard. This purges all caching layers on your site, including Object Caching.
I turned on Object Caching, but now I’m getting errors
Object Caching is a super beneficial tool to use on the WP Engine platform–it does come with some caveats, though. If you enable Object Caching and then start to see 502 errors on your site, this is most likely indicating that your wp_options table is storing some very large autoloaded data.
Autoloaded data is content stored in your site’s database – specifically, in the wp_options table. This is data that your site is required to load on every single page load. Some content (like your site’s siteurl, or home records) should load on every page, but not everything needs to! Object Caching stores these values as one long row. If the content that’s autoloaded surpasses the amount Object Caching can handle in one row, it rejects the request. WordPress, requiring the autoloaded data, sends the request again, and this causes a loop which eventually ends in a 502 error on the site.
Use the query below in phpMyAdmin to find out how much data is being autoloaded on your site, and which autoloaded rows are the longest:
SELECT LENGTH(option_value),option_name FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 20;
You can use this query to identify potential autoloaded data bottlenecks (which could also be causing overall slow performance on your website). If all the top items are things which should be loaded on each page load, it may be best to turn off Object Caching–this can be done from the Utilities page for any environment in your User Portal if ever needed.
To learn more about optimization opportunities for your WordPress website, check out our Database Optimization guide.