The upcoming WPSSO Core v3.48.0 release includes several changes to cache handling methods and filters.
If your site still uses the default WordPress transient cache in the database options table (most WordPress sites), you’ll find a new “Cache Status” metabox on the SSO > Plugin Dashboard and Features Status page.
If you’re using an external object cache, like APC, Memcache, Redis, Xcache, etc., this new metabox will not be displayed. Support for your chosen external object cache could be added at a later date, depending on user requests and the availability of an API to get (or count) all stored keys by prefix.
WPSSO version 3.37.0-2 has been released, along with updates to all its extensions. This latest WPSSO version includes several new options to fine-tune WPSSO’s internal caching features. The previous “Object Cache Expiry” option has been replaced with 7 new options:
- Head Markup Array Cache Expiry (default 3 days).
- Shortened URL Cache Expiry (default 1 week).
- List Column Content Cache Expiry (default 1 week).
- Filtered Content Text Cache Expiry (default 1 hour).
- Get Image (URL) Size Cache Expiry (default 1 day).
- Article Topics Array Cache Expiry (4 weeks).
- Schema Types Array Cache Expiry (4 weeks).
If you use a caching plugin, you may have an option to include custom PHP code when flushing the cache manually — for example, Comet Cache has an “Evaluate Custom PHP Code when Clearing the Cache?” option where you can enter additional PHP code to execute when clearing the cache manually. Adding the following code will also clear the WPSSO object cache when clearing the webpage cache:
if ( function_exists( 'wpsso_clear_all_cache' ) )
echo 'Cleared '.wpsso_clear_all_cache().
' files and objects from the WPSSO cache.<br/>';
I wrote a bash script this morning to report the size of WordPress cache folders, the number of files they contain, read each file to prime the OS disk cache, and optionally flush the OS disk cache as well. This might be a script you could execute to email a daily/weekly report of cache folder sizes, or perhaps execute during/after booting a server to prime the OS disk cache, or even on a regular schedule to make sure the OS cache is always primed. The script also has a “flush” argument to sync and drop the OS disk cache, which isn’t very useful (to me) except to see the difference in speed between a clean and primed cache (about 11s vs 0.4s for all websites on my server).
I recently added some disk caching for MySQL queries, WordPress objects, PHP opcode, and PHP web pages on my server. There are several different caching techniques and applications available, and memcached seems like one of the more popular ones. Right or wrong, it appears to be the default go-to for many developers these days.
Since I’m a SysAdmin by profession (with maybe a penchant for scripting and integration), I tend to have a more “systems” oriented approach — which led me to first consider, and then choose disk caching over memcached. In this post, I’ll outline the reasons I chose disk caching, and why in most circumstances it might be superior to memcached.
Over the past few weeks I’ve been looking at different solutions to improve the speed of my WordPress websites. The first step was to mirror and redirect the static content to another server (aka Content Delivery Network or CDN). I’m currently using a DreamHost VM, but I may look into using Amazon S3 as well. This is an easy way to save bandwidth, and off-load a web server that is configured for dynamic content (larger and slower). In the case of PHP and WordPress, there are several additional options available to improve local web server performance. I’ll describe the ones I’m currently using, including their expected impact to performance and short-comings. This article deals mainly with the local Apache Httpd and PHP configuration. There are additional infrastructure solutions that can improve performance, like using Nginx servers on the front, Varnish cache servers in the middle, and Apache Httpd on the back-end (for PHP and WordPress). This post is only about optimizing the Apache Httpd back-end. If you’re considering adding a Varnish server in front of Apache Httpd, you should probably avoid caching whole pages in Apache Httpd and leave that to the Varnish servers.