While page caching is sufficient for visitor traffic, database caching may be needed when there are too many bloggers and comment authors accessing the database simultaneously. When implementing database caching, care must be taken due to compatibility issues between plugins using the the db.php file. To implement database caching involves modifying the existing hyperdb db object (in db.php) to cache and retrieve the database objects. Before any development can commence, a determination is needed as to what part of the database object/structure needs to be cached and what is not to be cached.
Wordpress has built in memory caching via it’s object cache functions and uses local memory by default. This is an implicit caching model as only those items or object particularly in need of caching will be cached by invoking the object caching functions. The wordpress caching model can be overridden by adding an object-cache.php file in the wp-content directory. There is an available object-cache drop in for Memcache but that component must be fixed to enable memcache server pool replication. This replication is enabled by changing the memcache function invocation from addServer to implicit memcache add and then looping through the available memcache connections to add to each server within the pool. See the advanced-cache drop in for a good implementation of handling the memcache server pool connections. This ensures that only those memcache servers connections are available.
During the course of the discovery and development of WPTRUECACHE-HA, there were many questions and issues that arose for the proper approach for handling high availability web site infrastructure in a LAMP environment. For mission critical web sites, a truly open source solution may not be a suitable option. This being that Apache was not designed with high availability in mind nor was PHP. MySQL has a high availability version available. A true high availability LAMP infrastructure would involve building a custom version of Apache with PHP at a minimum. A group at www.linux-ha.org has an approach but it is incomplete.
Just building a cluster of failover services is neither sufficient nor using virtualization for the cluster. The underlying services and applications need adaptation for high availability environments.
Extreme care must be use when using Memcache for shred domain caching, as one domain can inadvertently clear (flush) the cached entries for all domains. This happens when the flush method is invoked as there is no distinguishing between domain cached content. To correct this problem, a custom Memcache PECL component must be built along with a custom memcache server to accept a server key for the flush command. There are presently two PECL memcache components (Memcache and Memcached), the difference is that Memcached provides support for a server key in additional to the hash key for all functions except the flush command.
Further research and discovery is needed.
The goal is to setup a pseudo production environment emulating the components of an high availability production system. The key services include a shared host with pecl memcache extension installed (may have to make a separate request from the hosting provider), a memcached server on a different server, and a CDN such as Cloudflare which offers a free entitlement.
To begin your shared cluster setup, follow these steps:
