Memcached no longer contributes, to how this site works… For the moment.

One of the facts which I had mentioned some time ago, was that on my Web-server I have a daemon running, which acts as a caching mechanism to any client-programs, that have the API to connect to it, and that daemon is called ‘memcached‘.

And, in order for this daemon to speed up the retrieval of blog-entries specifically, that reside in this blog, and that by default, need to be retrieved from a MySQL database, I had also installed a WordPress.org plugin named “MemcacheD Is Your Friend”. This WordPress plugin added a PHP script, to the PHP scrips that generally generate my HTML, but this plugin accelerated doing so in certain cases, by avoiding the MySQL database look-up.

In general, ‘memcached‘ is a process which I can install at will, because my server is my own computer, and which stores Key-Value pairs. Certain keys belong to WordPress look-ups by name, so that the most recent values, resulting from those keys, were being cached on my server (not on your browser), which in turn could make the retrieval of the most-commonly-asked-for postings – faster, for readers and their browsers.

Well, just this morning, my WordFence security suite reported the sad news to me, that this WordPress plugin has been “Abandoned” by its developer, who for some time was doing no maintenance or updates to it, and the use of which is now advised against.

If the plugin has in fact been abandoned in this way, it becomes a mistake for me to keep using it for two reasons:

  1. Updates to the core files of WordPress could create compatibility issues, which only the upkeep of the plugin by its developer could remedy.
  2. Eventually, security flaws can exist in its use, which hackers find, but which the original developer fails to patch.

And so I have now disabled this plugin, from my WordPress blog. My doing so could affect how quickly readers can retrieve certain postings, but should leave the retrieval time uniform for all postings, since WordPress can function fine without any caching, thank you.

memcached_1

Dirk

 

WordPress Update Went Smoothly Today.

I run a localized version of , 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 .

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 ‘‘. 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 ‘‘ 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.

Continue reading WordPress Update Went Smoothly Today.

Akonadi Server Update Successful Today

My Linux computers have PIM Software installed (…Personal Information Management), which is implemented with the KDE Desktop Manager, through a service which runs in user-space, called ‘Akonadi’. This service allows personal information to be synchronized across several platforms, including Google, Given the wishes of the user.

The most common way in which Akonadi is installed, is with its MySQL back-end for storing information locally, and doing so enables the software developers to run an instance of the MySQL database server, not as a system service, but by default as a localized instance, that accesses the folders of one user and only requires the user-name of one user.

According to this earlier posting, an update to the MySQL software itself, broke this way in which Akonadi works – probably because Debian developers did not coordinate that update with KDE developers. According to what I had written there, the system-wide package ‘mysql-server‘ needed to be installed, that also launches the system-wide daemon, before the form of it localized for use with Akonadi would run again. This upset the way I had installed my Laptop ‘Klystron’, where I had previously not thought it necessary to install the system-wide server, to enjoy the use of Akonadi.

Just this evening, KDE developers and Debian / Jessie package maintainers pushed through an update to several Akonadi-related packages, which I installed using my package manager. When we do this, user processes such as Akonadi are not restarted automatically, since in doing that, the package-manager would also break the current session.

And so what I needed to do in order to apply the update, was just to log out of my current, graphical desktop session, and log back in again.

But according to this earlier posting, there has been a history as well, of such attempted log-outs hanging, leaving just the mouse-pointer showing, and leading to no further, apparent progress in actually logging out. So, as of October 21, I had enabled the <Ctrl>+<Alt>+Backspace key-combination on all the desktop sessions, which needs to be arranged before the desktop session is started, so that I would effectively be able just ‘to blow away the current session’, in case a log-out hangs again.

This time around, while I was performing the log-out, my procedure did hang again, leaving me waiting for a few minutes, taking from 19h55 until 20h05 in total. But I did use the <Ctrl>+<Alt>+Backspace key-combination, to hasten the restart of the X-server, which meant that I was not forced to reboot the computer.

This turned the update into a Success, because system services such as the Apache Web-server and ‘memcached‘, and the system-wide MySQL database server, did not need to be restarted. And as a result, there was no disruption in any form to the blog or to my site.

Yay!

Now, Because I have the system-providing mysql-server package installed already both on my Laptop, as well as on this server-box ‘Phoenix’, I cannot tell whether this update did in fact fix that issue. Also, I cannot be sure that the update was meant to fix that issue. All I know, is that nothing is broken as it stands, and no services were disrupted.

Dirk