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.
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.
Because I am hosting this blog and Web-site on my own machine, I also get to choose certain details, like what type of caching service to run. I chose ‘memcached‘. The mere fact that this process runs on my computer, does not itself imply that WordPress knows how to use it, nor that WordPress registers its existence. However, there exists a plug-in at WordPress.org, that is named ‘Memcached Is Your Friend‘. And this plug-in acts as a single client to the daemon in question.
This deserves more elaboration. The way the Apache Web-server is set up on this box, it runs as a variable number of sub-processes, maybe 8-12, in case I receive a rapid number of hits. And each HTTP Request is executed independently by the Apache process in question. This means, that each request executes PHP-scripts synchronously, which pull in all the includes required for WordPress to function fully. The reason this is configured so, is the expectation on the part of Debian developers that I may be running their software on much-more-powerful hardware than I am in fact running it on.
Each of these invocations access my MySQL database for content to render as HTML, and may be slow.
(Edit 02/05/2017 : However, recent versions of WordPress also possess a so-called “Object Cache Framework”. )
The caching daemon caches the HTML which resulted from previous invocations, that may have been requested by other readers, or by concurrent Apache processes, asking for the same posting, but assumed to result in unchanging HTML. Hence, just as the PHP-scripts accessed MySQL, they also access the ‘memcached’ daemon first, (through the caching-framework), which works much more rapidly than MySQL did.
Okay. But with past WordPress builds, memcached was not always used. Now that it is being used more consistently, there are actually certain features of WordPress, which no longer work as well as they did before.
the Weather Widget in the sidebar is now cached. This is contrary to how a weather widget is supposed to work, which is that requests for the same widget, are supposed to reveal HTML which changes over time.
And so, to make certain features of my blog work better, I have written a cron-job which goes as follows (as root):
4 */6 * * * /etc/init.d/memcached restart >>/dev/null 2>>/dev/null
And so one improvement readers may notice from now on, is that the weather widget actually refreshes more than once per day, and that I may not need to post anymore, that we are having a snow-storm, because the weather-widget was somehow missing the fact.
(Edit 02/05/2017 : Actually, I am noticing myself, that the weather widget has resumed updating more often, than my cron-job runs. So I no longer claim to know, why it was not updating before. )
(Edit 02/04/2017 : ) I suppose that I might add the detail, although it seems a bit trivial, that when there is any sort of caching algorithm in-place, software which supports it also needs to have a way to mark a cached object as ‘dirty’, thus meaning that
the version in the cache has explicitly been marked as not-up-to-date, so that when the next attempt is made to retrieve that object, the cached version will not be used, but that rather a new version will be generated, and will replace the version in the cache.
(Edit 02/05/2017 : I think that I have applied incorrect terminology, due to how cache used in System Software and System Hardware is marked dirty, when the cache has been written to by the CPU, until the new contents are written out to the hard-drive, or to whatever slower form of storage is being cached.
The difference with WordPress is, that when the ‘Memcached Is Your Friend’ plug-in is being used, Key-Value Pairs need to be Deleted, when a new value is written to a widget, so that the next time that widget is viewed, the up-to-date version will be viewed – and also written into the cache.
I think it is up to the author of each plug-in to decide, whether it will use the caching framework or not. And then, such plug-ins as the Weather Widget may contain explicit code, to operate the cache.
A separate question arises, of whether built-in capabilities as ‘just to display postings’ will also use the Object Cache, and this needs to be decided in the WordPress core package. IMHO, It makes more sense if such capabilities do use it.
If this process is not working properly anymore, and two updates have taken place concurrently, such as WordPress and Post Views Counter, then I might want to question how long ‘Memcached Is Your Friend’ will remain compatible with the newest WordPress versions. )
Now, the Post Views Counter WordPress plug-in has a feature, to keep actual hits counted in the same object cache first, for a user-specified amount of time, before committing them to the database. This is a good feature to have, because depending on the hosting arrangement, access to the MySQL database may be slow, let us say because one Web-hosting service has many Web-sites.
But this in itself does not solve the problem described here, because even after the updated views count has been committed to the database, the PHP scripts still need to read the updated data there, to generate up-to-date HTML. But, the caching plug-in I use, inserts itself into a point before that happens. So even once the fresh data is committed to the DB, if a widget is being cached, the DB will not be queried, every time that widget is to be displayed.
(Edit 02/05/2017 : I think that the author of Post Views Counter intended to use this object cache himself, but did not take into account, that some of his users might also be using Memcached Is Your Friend, etc., in order to cache All The HTML which WordPress is sending to the browsers. )
It is my present assumption that the core PHP-code has been optimized for speed a little bit, and that because this was done, my caching plug-in is also being invoked more frequently.
If all this strikes the reader as slightly complicated, do not worry, I too can sometimes misinterpret the information.
According to the cron-job I created, ‘memcached’ was restarted once at midnight, and then once-again at 6h04, and then again at 12h04.
I looked at my dashboard for the first time today, around 11h00, and saw that apparently, 131 views of my postings had taken place. But then, just to test the system again, I looked at the dashboard widget after 12h04, and saw that ‘only’ 134 views have taken place:
According to what I have written, it might seem that only 3 views took place, between 6h04 and 12h04 today. This might cause an author like me to worry, that access to my server stopped shortly after 6h04.
But this is not what happened. In reality, the 131 views which I saw displayed close to 11h00 this morning, were an up-to-the-minute figure, because that view of the dashboard-widget, was also the first time since 6h04, that the widget was displayed. So at 11h00, there was no HTML view of the widget in the cache, and an up-to-date view was placed there.
What the data seems to suggest, is that only 3 more views of the blog took place, between 11h00 and 12h04. I can look forward to seeing a much higher views-count there, when I invoke this widget again, after 18h04 tonight.
At 18h00, that same widget still only showed that my individual postings had been viewed 134 times. But at 18h04 I was able to press <F5>, and after some delay, the dashboard-page updated, to show me 161 views:
I guess I am having a slow day. But either way, it is not likely that my blog has been read 27 times, between 18h00 and 18h04 .