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.

Dirk

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.

Continue reading An Update on how the Object Cache works, in WordPress

Monthly Log Rotation Disrupted my IPv6 Today.

One of the tasks which a Debian / Linux system does, is log-rotations at regular intervals. Some log-rotations take place daily, others weekly, and others monthly.

When log files are rotated, the services that generate them must usually be restarted, although there are a very few daemons which can simply be commanded to reopen their log file. This needs to be done, because even when the name of the log file has been changed (by the log-rotation), the file handle which its process has, still points to the same file. So most generally, the service is also restarted, so that it can open a new log-file, with the name of the old log-file, which was rotated to having a new file-name.

I have two services installed, to which this is relevant today. One of them is my “OpenVPN Server”, and the other is my “Teredo Client”. The Teredo Client was already configured by package maintainers, not to do any log-rotations. But my OpenVPN Server does a log-rotation on a monthly basis.

One of the facts about how my system reacts is in practice, that when my OpenVPN Server does a restart, it also incapacitates my Teredo Client. I am not sure why this happens, but it is completely consistent behavior. It has something to do with how my dual-stack kernel manages its IPv6 addresses.

So today, being July 1, saw a log-rotation to my OpenVPN Server, which also took out my Teredo Client, at the time the monthly log-rotations are supposed to take place, in a 100% predictable manner. I needed to restart the Teredo Client, in order to get my IPv6 address back, by about 14h15 this afternoon. From about 6h00 until 14h15 today, this site had no working IPv6 address.

I apologize for any inconvenience.

Dirk

 

How I fixed my Chrome for Linux Package Issue

In a previous posting, I described a specific issue I was having, with my Linux installation of Google Chrome.

I have now found a solution to this exact problem.

Chrome for Linux installs a daily cron job, which resets the file

/etc/apt/sources.list.d/google-chrome.list

by default. If it is absolutely necessary to override this behavior, let us say because our package manager is set up by default to pull both the 32-bit and the 64-bit contents of any repository, but the latest build of Chrome only supports a 64-bit architecture, then there is a configuration file named

/etc/default/google-chrome

This file defaults to containing


repo_add_once="false"
repo_reenable_on_distupgrade="true"

This can be changed to


repo_add_once="true"
repo_reenable_on_distupgrade="true"

Dirk

(Edit 02/06/2016 : ) Unfortunately, I have discovered that the variables defined in

/etc/default/google-chrome

Do Not change the behavior of the cron job, to rewrite the file

/etc/apt/sources.list.d/google-chrome.list

And so I found that slightly more aggressive editing was needed by be.

On standard Debian / Linux systems, the daily cron jobs associated with specific packages are stored in the directory

/etc/cron.daily

And there is a symlink in this directory, pointing to a target file, which is the script that Google Chrome runs. I did not take out the symlink. But I have changed the permission bits of the target file, to make that non-executable.