SQLite Object Cache

Yes. To see the Settings page, choose Settings > Object Cache from the first site, or any site, in the multisite installation.

Exactly predicting each site’s speedup is not possible. Still, benchmarking results are promising. Please see this. If you run a benchmark, please let the author know by leaving a comment on that page or using the support forum.

The default setting for Cached Data Size is 4 MiB. This plugin allows the actual cached data size to grow larger than that, and occasionally removes old data to trim back the size to the setting. Take a look at the Statistics page. If your actual cached data setting is consistently larger than the setting, double the setting.

If you operate a large and busy site, try an initial setting of 32 MiB, then adjust it based on the growth of the actual size.

SQLite is fast and efficient database software. It doesn’t require a separate server. Instead, it is built into php using the SQLite3 extension. SQLite programs don’t need to open network connections to send requests and wait for replies.

No. Your MariaDB or MySQL database sql server still holds all your content. All your site’s imports, exports, backups and other database operations continue to function normally. This plugin uses SQLite simply to hold named values. For example, a value named “post|3” will hold a temporary, easy-to-retrieve cached copy of post number 3. When it needs that post, WordPress can fetch it quickly from SQLite.

No, you don’t. This plugin doesn’t use SQLite as a full-fledged database server.

A persistent object cache needs some kind of storage mechanism. SQLite serves this plugin as a fast and simple key / value storage mechanism.

Some hosting providers offer scalable high-performance redis cache servers. If your provider offers redis, it is a good choice. You can use it via Redis Object Cache plugin. Sites using redis have one SQL database and another non-SQL storage scheme: redis. Other hosting providers offer memcached, which has the Memcached Object Cache.

But many hosting providers don’t offer either redis or memcached, while they do offer SQLite. This plugin enables your site to use a persistent object cache even without a separate cache server.

Probably. Page caching and persistent object caching are completely separate functions in WordPress. But, some multi-feature caching plugins support optional object caching using redis or memcached. If that feature is enabled in your page cache plugin, you should not use this plugin.

You can find out whether your page-cache plugin also enables persistent object caching. Look at the Drop-in section of the Plugins -> Installed Plugins page. If it mentions the drop-in called “object-cache.php” then your page cache plugin is handling persistent object caching and you should not use this plugin.

Users of this plugin have found that it works well with WP Rocket, LiteSpeed Cache, WP Total Cache, WP Super Cache, and WP Fastest Cache. It also works with Cloudflare and other content delivery networks. The author has not learned of any incompatibilities in this area. (If you find one please start a support topic!)

Yes. It does not require any specific database server version.

It does not use either. Please do not use this plugin if you have access to redis or memcached. Instead, use the Redis Object Cache or Memcached Object Cache plugin.

In WordPress, as in many web frameworks, your database server is a performance bottleneck. Using some other mechanism for the object cache avoids adding to your database workload. Web servers serve pages using multiple php processes, and each process handles its own SQLite workload while updating a shared database file. That spreads the object-cache workload out over many processes rather than centralizing it.

No. It’s a cache, and everything in it is ephemeral. When WordPress cannot find what it needs in the cache, it simply recomputes it or refetches it from the database.

To avoid backing up SQLite files, tell your backup plugin to skip the files named *.sqlite, *.sqlite-wal, and *.sqlite-shm.

This plugin automatically suppresses backing up your SQLite data when you use the Updraft Plus, BackWPUp, or WP STAGING plugins. The Duplicator plugin does not offer an automated way to suppress copying those files.

If you use some other backup or cloning plugin, please let the author know by creating a support topic.

No. You only need one persistent object cache, and WordPress only supports one.

No. If you have more than one web server this doesn’t work correctly. If you operate at that scale, use redis or some other cache server. (If you aren’t sure whether you have a load-balanced installation, you almost certainly do not.)

Yes, but you must activate this plugin first before you activate Performance Lab. And, you must deactivate Performance Lab before deactivating this plugin last.

The Performance Lab plugin offers some advanced and experimental ways of making your site faster. One of its features uses object-cache initialization code to start tracking performance. So there’s a required order of activation if you want both to work.

Use transients to store your cacheable data. WordPress’s Transient API uses persistent object caching if it’s available, and the MariaDB or MySQL database when it isn’t. The Metadata API and Options API also use persistent object caching.

This plugin uses a WordPress drop-in to extend the functionality of the WP_Cache class. When you activate the plugin it creates the dropin file .../wp-content/object-cache.php. Upon deactivation, it removes that file and the cached data.

It’s in your site’s wp_content directory, in the file named .ht.object-cache.sqlite. That file’s name has the .ht. prefix to prevent your web server from allowing it to be downloaded. SQLite also sometimes uses the files named .ht.object-cache.sqlite-shm and .ht.object-cache.sqlite-wal, so you may see any of those files.

On Linux and other UNIX-derived operating systems, you must give the command ls -a to see files when their names begin with a dot.

Putting your .sqlite files outside your site’s document root is good security practice. This is how you do it. If you define the constant WP_SQLITE_OBJECT_CACHE_DB_FILE in wp_config.php the plugin uses that for sqlite’s file pathname instead. For example, if wp-config.php contains this line

define( 'WP_SQLITE_OBJECT_CACHE_DB_FILE', '/tmp/mysite-object-cache.sqlite' );

your object cache data goes into the /tmp folder in a file named mysite-object-cache.sqlite.

You can also define WP_CACHE_KEY_SALT to be a text string. Continuing the example, this line

define( 'WP_CACHE_KEY_SALT', 'qrstuv' );

causes your object cache data to go into the /tmp folder in a file named mysite-object-cache.qrstuv.sqlite.

Yes. You can use your OS’s memory map feature to access and share cache data with SQLite Memory-Mapped I/O. On some server configurations this allows multiple php processes to share cached data more quickly. In the plugin this is disabled by default. You can enable it by telling the plugin how many MiB to use for memory mapping. For example, this wp-config setting tells the plugin to use 32MiB.

define( 'WP_SQLITE_OBJECT_CACHE_MMAP_SIZE', 32 );

Notice that using memory-mapped I/O may not help performance in the highly concurrent environment of a busy web server.

Some sites occasionally generate error messages looking like this one:

Unable to execute statement: database is locked in /var/www/wp-content/object-cache.php:1234

This can happen if your server places your WordPress files on network-attached storage (that is, on a network drive). To solve this, store your cached data on a locally attached drive. See the question about storing your data in a more secure place. It also can happen in a very busy site.

Sometimes WP-CLI commands issued from a shell run with a different user from the web server. This plugin creates one or more object-cache files. An object-cache file may not be readable or writeable by the web server if it was created by the wp-cli user. Or the other way around.

On Linux, you can run your WP-CLI shell commands like this: sudo -u www-data wp config list This ensures they run with the same user as the web server.

Please read this.

Q: What are the two hardest things to get right in computer science?

1. Caching things.
2. Naming things.
3. Coping with off-by-one errors.

Seriously, the core of WordPress has already worked out, over years of development and millions of sites, how to cache things and name them. This plugin simply extends that mechanism to make those things persistent.

Please look for more questions and answers here. Or ask your question in the support forum.