A
persistent object cache helps your site perform well. This one uses the widely available
SQLite3 extension, and optionally the
igbinary and
APCu extensions to php. Many hosting services offer those extensions, and they are easy to install on a server you control.
What is this about?
It's about making your site's web server perform better. An object cache does that by reducing the workload on your MariaDB or MySQL database. This is not a
page cache; these persistent objects go into a different kind of cache. These objects aren't chunks of web pages ready for people to view in their browsers, they are data objects for use by the WordPress software.
Caches are ubiquitous in computing, and WordPress has its own caching subsystem. Caches contain short-term copies of the results of expensive database lookups or computations, and allow software to use the copy rather than repeating the expensive operation. This plugin (like other object-caching plugins) extends WordPress's caching subsystem to save those short-term copies from page view to page view. WordPress's cache happens to be a
memoization cache.
Without a persistent object cache, every WordPress page view must use your MariaDB or MySQL database server to retrieve everything about your site. When a user requests a page, WordPress starts from scratch and loads everything it needs from your database server. Only then can it deliver content to your user. With a persistent object cache, WordPress immediately loads much of the information it needs. This lightens the load on your database server and delivers content to your users faster.
Who should use this?
If your site runs on a single web server machine, and that server provides the
SQLite3 and
igbinary extensions to php, this plugin will almost certainly make your site work faster. And if that server provides the
APCu extension, this plugin uses it too.
Some hosting providers offer
redis cache servers. If your provider offers redis, it may be a good choice. You can use it via tbe
Redis Object Cache plugin. Sites using redis have one SQL database and another non-SQL storage server: redis. Other hosting providers offer
memcached, which has the
Memcached Object Cache plugin. And some large multipurpose cache plugins, such as the
LiteSpeed Cache, also offer object caching based on one of those cache server software packages.
The cache-server approach to object caching comes into its own when you have multiple load-balanced web server machines handling your site. SQLite doesn't work correctly in a multiple-web-server environment.
But, for single-server site configurations, SQLite, possibly assisted by APCu, performs well. And the vast majority of sites are single-server.
APCu
APCu is an in-memory storage medium. It lets php programs, like WordPress, store data in shared memory so it's very fast to retrieve when needed. If APCu is available on your host server, you can configure this plugin to use it. It reduces the typical cache lookup time to one-fifth or less of the SQLite lookup time, which is itself a few tens of microseconds. Performance counts, especially on busy web sites.
Please look at
Installation to learn how to configure this plugin to use APCu. The plugin works fast without it, and faster with it.
WP-CLI: Even if APCu is in use, caching with SQLite is necessary when your web site uses WP-CLI, because WP-CLI programs do not have acces to the APCu cache. This plugin writes all cached data both to APCu and to SQLite and makes sure the two are synchronized.
WP-CLI
You can control this plugin via WP-CLI once you activate it. Please type this command into your shell for details.
wp help sqlite-object-cache
Credits
Thanks to
Till Krüss. His
Redis Object Cache plugin serves as a model for this one. And thanks to
Ari Stathopoulos and
Jonny Harris for reviewing this. Props to Matt Jones for finding and fixing a bug that appeared on a heavily loaded system. Thanks to
Massimo Villa for testing help, and to
nickchomey for a comprehensive code review. All defects are, of course, entirely the author's responsibility.
And thanks to Jetbrains for the use of their software development tools, especially
PhpStorm. It's hard to imagine how a plugin like this one could be developed without PhpStorm's tools for exploring epic code bases like WordPress's.
How can I learn more about making my WordPress site more efficient?
We offer several plugins to help with your site's database efficiency. You can
read about them here.
For this plugin to work for you, your server
must have the
SQLite3 extension to php installed.
If you have the
igbinary and
APCu extensions, this plugin uses them to work more efficiently. But it works without them.
Installing "SQLite Object Cache" can be done either by searching for "SQLite Object Cache" via the "Plugins > Add New" screen in your WordPress dashboard, or by using the following steps:
- Download the plugin via WordPress.org
- Upload the ZIP file through the 'Plugins > Add New > Upload' screen in your WordPress dashboard
- Activate the plugin through the 'Plugins' menu in WordPress
Or, use these WP-CLI commands to install the plugin, secure it, activate it, and set the cache size to 32MiB.
wp plugin install sqlite-object-cache wp config set WP_CACHE_KEY_SALT $(openssl rand -base64 12) wp plugin activate sqlite-object-cache wp sqlite-object-cache size 32
The plugin offers a few optional settings for your
wp-config.php
file. If you change them, deactivate the plugin first, then change them, then reactivate the plugin.
- WP_CACHE_KEY_SALT. Set this to a hard-to-guess random value to make your cache keys harder to guess. This setting works for other cache plugins as well.
- WP_SQLITE_OBJECT_CACHE_SERIALIZE. When true, this forces the plugin to use 's serialize() scheme to store cached data in SQLite. If this is not set, the plugin uses the more efficient igbinary scheme if it is available.
- WP_SQLITE_OBJECT_CACHE_DB_FILE. This is the SQLite file pathname. The default is
…/wp-content/.ht.object_cache.sqlite
. Use this if you want to place the SQLite cache file outside your document root.
- WP_SQLITE_OBJECT_CACHE_TIMEOUT. This is the SQLite timeout in milliseconds. Default: 5000. (Notice that the times shown in the Statistics tab are in microseconds if you compare them to this timeout setting.)
- WP_SQLITE_OBJECT_CACHE_JOURNAL_MODE. This is the SQLite journal mode. Default: ‘WAL’. Possible values DELETE | TRUNCATE | PERSIST | MEMORY | WAL | WAL2 | NONE. (Not all SQLite3 implementations handle WAL2.)
- WP_SQLITE_OBJECT_CACHE_APCU. If true enables cache acceleration with APCu RAM. This setting can be updated from the plugin's Settings page.
Configuring the cache key salt
When multiple sites share the same server hardware and software, they can sometimes share the same cache data. Setting
WP_CACHE_KEY_SALT
to a hard-to-guess random value for each site makes it much harder for one site to get another site's data. Notice that this
WP_CACHE_KEY_SALT
value must be set, in your site's
wp-config.php
file, before activating your persistent object cache plugin. This works for other object cache plugins too.
To set the value put a line like this in
wp-config.php
.
define( 'WP_CACHE_KEY_SALT', 'Random_t6xJix' );
Of course, use your own random value, not the one in this example. You can get one from your Linux command line shell with the
openssl rand -base64 12
. Or, if you use WP-CLI you can set the value directly with
wp config set WP_CACHE_KEY_SALT $(openssl rand -base64 12)
Configuring and Using APCu
APCu is an in-memory storage medium. If APCu is available on your host server, you can configure this plugin to use it. There is an option to enable it on the plugin's Settings page. Or you can do it manually. Put a WP_SQLITE_OBJECT_CACHE_APCU value of
true
into your
wp-config.php
file. You can use this WP-CLI command to do that.
wp config set --raw WP_SQLITE_OBJECT_CACHE_APCU true
Or, you can edit your
wp-config.php
file to add this line.
define( 'WP_SQLITE_OBJECT_CACHE_APCU', true );
1.5.1
- Provide APCu opt-in on the settings page.
1.5.0
- Use APCu to increase performance if it is available and if WP_SQLITE_OBJECT_CACHE_APCU is defined.
1.4.1
- More efficient testing for drop-in validity.
- More accurate least-recently-updated cleanup.
1.4.0
- Add WP-CLI support.
- Make sure to close .sqlite files to avoid file-descriptor leaks in long-running processes. Props to Matt Jones.
1.3.8
Add some support for new SQLite WAL2 write-ahead logging.
Support WordPress 6.5.