WpW: Object Cache Support in LSCache
Welcome to another installment of WordPress Wednesday!
Today’s topic is: Object Cache Support in LSCache
Disclaimer: The information contained in this post is accurate for LSCWP v1.8.3 [release log]. If you are using a newer version of the plugin, some details may have changed. Please refer to our wiki for the latest!
You asked for it, and we delivered. LiteSpeed Cache for WordPress now supports Object Cache!
What is an Object Cache?
An object cache stores the results of expensive and/or frequent database queries in a way that makes them easy to retrieve, and eliminates the need for repeated access to the database. Object caching greatly reduces the time it takes to retrieve query results.
For example, WordPress stores your site’s options in the database. Site options include things like the site’s name and URL. Every time WP assembles a page for a visitor, it is necessary to access the database to read the site options. As you can imagine, these repeated queries for the same information represent wasted resources. With an object cache, you can query the database once, and save the results for a set period of time. During that time, whenever a page must be assembled, WordPress can get the site information from the object cache. Accessing object cache is a much less resource-intensive prospect than accessing a database.
Some queries are time-consuming, and other queries are repeated frequently. Both of these scenarios can be improved by storing the query results in object cache.
Note: If you have a site that is fully-cached by LSCWP, object cache won’t be invoked very often. Object cache is only necessary when WordPress is building a page through PHP. If PHP is not being called (and minimizing PHP usage is the goal with LSCache, after all) then there are no queries to process and therefore nothing to look up in object cache.
How to set up Object Cache Support
LSCWP doesn’t provide object caching directly. Rather, it supports your use of an external object cache such as Redis, Memcached or LiteSpeed’s drop-in Memcached replacement, LSCMCD. Setting up object cache systems is outside of the scope of this tutorial, but you can find some useful information via the product links above or by visiting our wiki.
So, assuming you are already using one of these object caching methods, you can set up LSCWP support in the Cache Settings tab.
Navigate to LiteSpeed Cache > Settings > Cache and scroll down to Object Cache. (Make sure you are in Advanced View, or the Object Cache settings will not be visible.) You will need to give LSCWP some parameters, including where your Redis, Memcached or LSMCD lives, which objects you’d like to have cached, and how long you want objects to remain in cache, among other things.
NOTE: In the imminent LSCWP v1.8.4, Object Cache settings are moving to a new tab. If you are running v1.8.4+, please Navigate to LiteSpeed Cache > Settings > Advanced to access the following settings.
Object Cache is disabled by default. Select
ON to enable it and then configure it via the settings, as described below.
Memcached if using Memcached or LSMCD. Choose
Redis if using Redis.
Host and Port
These settings refer to the hostname (or IP address) and port number used by your object cache. The default values of
11211 should work fine for you, if your cache is set up via a TCP connection. If you are using a UNIX socket, Host should be set to
/path/to/memcached.sock (substitute the actual path used for your installation) and Port should be set to
Default Object Lifetime
Choose a TTL for items stored in the object cache. We recommend using a relatively short time in order to avoid stale results. Default is 360 seconds.
This is an informational area to let you know the status of your external object cache. If you are getting errors here, please see How to Debug your Object Cache Setup.
Username, Password, and Redis Database ID
These settings may or may not be available, depending on your object cache setup. If you see any of these fields, fill in the appropriate credentials. Doing so will prevent cross-contamination in situations where one object cache is shared among multiple sites.
This is a list of groups that should be cached at the network level. By default:
users userlogins usermeta user_meta site-transient site-options site-lookup blog-lookup blog-details rss global-posts blog-id-cache
Do Not Cache Groups
These groups should not be included in object cache. By default:
comment counts plugins
If enabled, the connection is kept alive in order to make Memcached faster. This is set to
ON by default.
Cache WP Admin
If enabled, WordPress admin will be sped up, but at the risk of occasionally retrieving stale data from the object cache. This is set to
OFF by default.
When Cache WP Admin is set to
OFF, transients have nowhere to go. Without transients, you don’t receive server status notices (such as
XXXX has been completed successfully.). Enable Store Transients to get server notices when Cache WP Admin is disabled.
Why do You Need LSCache for This?
You may be wondering: what is the point of setting up object cache support in the LSCache plugin?
So here’s the thing: you can’t use object cache without telling WordPress how to handle it. You need a plugin for that. You can install a single-purpose object cache plugin, or you can let LSCache facilitate the relationship between your object cache and WordPress.
It comes down to this: would you rather install several plugins with many different interfaces to handle all of your optimization needs? Or would you rather have one optimization plugin that can handle it all? If you like the second option, then LSCache is your solution!
Have some of your own ideas for future WordPress Wednesday topics? Leave us a comment!
Don’t forget to meet us back here next week for the next installment. In the meantime, here are a few other things you can do:
- Subscribe to the WordPress Wednesday RSS feed
- Download LiteSpeed Cache for WordPress plugin
- Learn more about the plugin on our website