## New Policy Regarding memcached

One of the facts which I’ve written about at length, is that while my home-computer ‘Phoenix’ has acted well as my Web-server, I am aiming to improve its performance as much as possible through caching, and through the daemon named ‘memcached‘ specifically. I have a new plugin installed on my blogging engine, which connects to memcached, and this plugin tries to cache a larger set of categories, of object-types that exist within the WordPress blogging engine.

One of the less-fortunate side-effects of this is, that every time, after I update my other plugins, there are malfunctions, due to WordPress not recognizing that the plugins in question have been updated to their new version.

There is a logical solution to this problem, which should work, which is to restart memcached after each plugin-update. This should be harmless and flush the cache.

Again, a less-fortunate side-effect of this policy will be, that the site will seem a bit slow, after each plugin-update, and that indeed, I will not announce memcached restarts anymore.

A fortunate side-effect of how much the new plugin caches is, that it seems to be improving the performance of the site more, than the old caching plugin did. It almost seems to have become possible, that WordPress is serving out the blog, while accessing the actual hard-drive infrequently.

Dirk

## And Now, Memcached Contributes to This Site Again!

According to this earlier posting, I had just uninstalled a WordPress plugin from my server, which uses the ‘memcached‘ daemon as a back-end, to cache blog content, namely, content most-frequently requested by readers. My reason for uninstalling that one, was the warning from my WordFence security suite, that that plugin had been abandoned by its author.

Well, it’s not as if everything was a monopoly. Since then, I have found another caching plugin, that again uses the ‘memcached‘ daemon. It is now up and running.

(Screenshot Updated 06/19/2017 : )

One valid question which readers might ask would be, ‘Why does memcached waste a certain amount of memory, and then allocate more, even if all the allocated memory is not being used?’

(Posting Updated 06/21/2017 … )

## 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 WordPress, without really knowing how the latter works in detail, because I have never written a WordPress 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 Post Views Counter, 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.

Dirk

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

## WordPress Update Went Smoothly Today.

I run a localized version of WordPress, that partially comes from my Linux package manager, but that has been modified by me, to allow me to install the plug-ins and extensions from WordPress.org .

Therefore, whenever an update to the core files is available from Debian Team – from the package manager – I am a little apprehensive, that the way this update is carried out might not be compatible with my customizations.

Most of the time, updates are good, but on occasion, they may break things.

Today an update to the core package came through the package manager, which technically puts my version at ‘4.1+dfsg-1+deb8u12′. I am sure that there are benefits to users like me. But most importantly, it seems that this update did not break anything. Yay!

Also, I am not recording any down-time, because as far as I can tell, I was able to display a Maintenance Mode page, while the update took place, which would have told readers that the site is undergoing maintenance, for a few minutes.

Dirk

P.S. I also had to restart my ‘memcached’ daemon after that, the purpose of which is to introduce caching on my side – on the server – to speed up retrieval of whatever readers are interested in most often. Because this cache has therefore been flushed, some of the pages and postings may load a little slowly for the next day or two.

(Edit 02/03/2017 : ) I have begun to notice some functional changes in the behavior of WordPress, that I believe stem from this update. In short, the new version seems to use my caching daemon more consistently, than the previous build did.