An Update on how the Object Cache works, in WordPress

In this earlier posting, I had added comments that describe caching in general, as well as the Object Cache of , without really knowing how the latter works in detail, because I have never written a plug-in.

There was a fact which I had never mentioned, that in the caching daemon, each Key-Value Pair has a time-stamp, indicating exactly when the Value was set. Apparently, when plug-in designers query the MySQL database, they have the option to make that a cached query, which means that the query will first query the cache, and only if there is no Value in the cache, will query the database.

This query has as optional parameter, an expiry time, so that if the Value in the cache is older than this time, it will be regarded as not being in the cache.

I suppose this is useful in certain cases, where there is no opportunity to delete the Key in the cache when data is updated, but in which to view a widget simply looks up some value in the database, which could be cached.

I have communicated with the author of , who has told me that he has in fact modified his plug-in, to add an expiry value to his cached queries, to try to solve the problem of data-views not updating, since the last plug-in update. And I have also installed the latest version of his plug-in, which contains his patch.

I suppose that one question this revelation raises, is whether it is in fact a part of what gets cached, pieces of HTML that constitute whole postings, at the request of core PHP code. It may not be. Instead, it may only be the case that HTML continues to be generated by PHP code, on the basis of database queries, but that more of those queries may be cached queries now.

However, the actual HTML of which my postings consist, is obtained by queries to the database.


Note: The patch which this plug-in author has applied to his code, does in fact work, and I can safely delete the which I had created as a workaround.

Now, I could engage in some brazen speculation, based on my experiences with this plug-in, and on my communications with its author. This speculation should not be considered a certainty.

It might be, that in the latest update to the core package, its maintainers have simply decided, that If an Object Cache exists – because one user installed a suitable back-end – all DB queries should be regarded as cached queries by default. This would be an ambitious way to improve performance, but would also cause numerous plug-ins to start misbehaving, because their authors might not be expecting this.

The reason I take this speculation semi-seriously, is the fact that used to work. Previously, even though I had caching installed, plug-in code did not need to be modified by its author, to display in its widget what the database stated. So there needed to be some reason, why code which he had not yet modified, would suddenly stop working…

For the sake of argument, there could exist some API functions which completely replace a Key, and which therefore also delete it from the cache – invisibly to plug-in designers. And there could be other API functions which merely increment a numeric Value referenced by a Key, and which may not delete the same Key from the cache…

(Edit 02/07/2017 : I am certain that when I edit my postings, the cache Keys do get deleted. However, this capability is provided by the core package, and not by API functions made available to plug-in designers.)


I suppose that it would be possible for the API designers to make it so, that even when a trivial instruction is given just to increment a numeric Value, the Key in the cache that points to it should also be deleted. However, I can see a specific reason not to do so.

The data in question is a hit-counter. It will literally get updated every time one browser accesses the blog. If the cache needed to get flushed in some way every time, this would present a performance-drain.

The author of this hit-counter has already created his own custom Keys, which he can manipulate as he wishes, before deciding to commit anything to the database. His purpose was not to allow a fast rate of visitors to slow down engine performance.

I, the admin of my own blog, am the only person in practice, who ever views the results. I only do so less frequently, than the rate at which visitors come to my blog. Performance is better, if the cached entry is only obsoleted, due to my own views of the data.


Print Friendly, PDF & Email

One thought on “An Update on how the Object Cache works, in WordPress”

Leave a Reply

Your email address will not be published. Required fields are marked *

Please Prove You Are Not A Robot *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>