I won’t laugh at a MVS / IDMS / CICS background. That stuff worked (still works?) really well at scale.
The background of this caching mess: And a mess it is.
php has the “fifty first dates” problem. Every single pageview / endpoint invoction it serves starts a completely new instance, and it has no RAM-resident context for to help it handle the pageview (or REST endpoint invocation or whatever). This sets it apart from web servers built on, for example, nodejs. Those handle many requests with a single process in which data structures persist from request to request. So a nodejs server feeds each browser a session cookie, and then uses its (random) value to look up session structures on each request from that browser.
But not php. In the olden days php was a pure interpreter, and had to read and parse all the .php files for each request. So, the Zend people added the op cache, to allow parsing and caching the code. WordPress php code uses the op cache. And they added a session subsystem, which fed cookies to browsers and then used file system files to store session values. (WordPress doesn’t use that session subsystem.) It was possible to extend the session subsystem to store session values in a dbms, or any arbitrary key-value storage system. Keep in mind that all this stuff was pre-SSD storage devices, and designed for old-school rotating DASD.
Enter redis and memcached. These are competing client-server key-value stores. They’re designed to be fast on old-school hardware, by avoiding the file system and storing data in RAM.
At the same time WordPress was getting a big following with people wanting to scale it up. They added a formal WP_Object_Cache API capable of avoiding multiple round-trips to the DBMS (MySQL and more recently MariaDB) for the same information in the same page view. And, they designed it to allow persisting cached objects from page view to page view. Some plugin developers figured out how to do that persisting. One was Till Krüss, who used redis for storage. Another couple of projects used memcached for the purpose. If you have a site and want to use either of those strategies you need a hosting service that provides the appropriate client-server key-value store. Most hosting services don’t. If you run your own machines or VMs, running redis or memcached isn’t a big deal, but if you use a hosting service, most of them don’t have a clue about this.
Nawawi Jamili came up, in Docket Cache, with the really creative idea of persisting the cached objects to php source code, and then using the php op cache to avoid reparsing that source code, and so using the op cache as a data cache.
And, I, with the task of supporting a fairly large WooCommerce store on GoDaddy hosting (where I swear some of their software is older than CICS) looked at a bunch of alternative storage mechanisms. I investigated SysV Shared Memory and some sort of message-queuing system, and then settled on using the SQLite in-process DBMS as the key-value store. So that’s how this plugin came to be.
Notice that this is all about object caching. The WordPress ecosystem has a bunch of alternative approaches to page caching, which is an entirely different thing.
I hope this background helps you figure out this, umm, mess.
