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 using a search bar on a site to search for an article. When you hit “enter” to search, the site makes a query to the database to ask for the data you searched for and return results like posts and pages.
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 our 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.
If you experience this issue, you can resolve it by either visiting the User Portal under phpMyAdmin on the Overview page for your environment, and setting large database rows in wp_options to no in the autoload column. If you’re not familiar with this process, seek a developer’s help first! Or, you can resolve the issue by disabling Object Caching. Object Caching can be enabled or disabled as needed, from your User Portal under the Utilities page from the Overview for each environment.
