Supercharge your WP Object Cache with LCache, a persistent, performant, and multi-layer cache library.
FAQ
Do you have benchmarks you can share?
We’ve done some rudimentary testing with New Relic on Pantheon infrastructure. The results were substantial enough for us to begin using LCache in production. Watch David Strauss’ DrupalCon presentation for a more thorough explanation.
If you’d like to do some benchmarking yourself, we’d love to hear about your testing methodology and conclusions. Caching is more of an art than a science, and outcomes can vary. Because cost of network transactions is one of the problems solved by WP LCache, the performance gains will be more impressive if you’ve historically been using Redis or Memcached on a separate machine.
Is APCu persistent like Redis is?
APCu is persistent through the life of a PHP-FPM process. However, unlike Redis, APCu doesn’t save its state to disk at shutdown. When PHP-FPM is restarted, WP LCache will repopulate the L1 cache (APCu) from the L2 cache (database).
Why am I seeing heavy database load from WP LCache?
When you first enable WP LCache, you’ll have a good amount of database activity as it writes all cache entries to the database. Eventually, as long as your codebase is optimized, database activity will die down and most activity will be in APCu.
However, if your codebase isn’t optimized, you’ll see continued database load. Some common issues include:
- Frequent calls to
wp_cache_flush(), which empties the entire cache and requires the L2 to be completely repopulated.
- Redundant or duplicative calls to
wp_cache_set(), where code paths hardly ever use the cache values they set.
In both of these cases, any persistent object cache drop-in probably isn’t going to be useful until you solve your code problems.
ChangeLog
0.6.1 (October 3rd, 2017)
- Switches back to
utf8 for LCache tables [#149].
0.6.0 (August 28th, 2017)
0.5.2 (May 3rd, 2017)
- Normalizes address key to comply with DB column length.
- Always runs database table initialization on the
enable CLI command.
- Doesn’t require APCu to be enabled in CLI.
- Test improvements.
0.5.1 (April 25th, 2017)
- Uses the correct DSN format in all DB_HOST scenarios.
- Only loads LCache library for PHP 5.6+, to ensure WordPress doesn’t fatal on older versions.
- Test improvements.
0.5.0 (November 2nd, 2016)
- Splits WordPress’ alloptions cache into separate cache keys to mitigate cache pollution caused by race conditions. See #31245 for further detail.
- Emits warnings in CLI when LCache isn’t properly configured.
- Incorporates a variety of test suite improvements.
0.4.0 (October 5th, 2016)
- Switches to stub file approach for enabling object cache drop-in, because symlink changes aren’t detected by opcode cache in PHP 5.5+.
0.3.1 (September 22nd, 2016)
- Updates LCache to v0.3.4, which automatically detects and handles misuse of the TTL as an expiration timestamp.
0.3.0 (September 21st, 2016)
- Introduces the
wp lcache enable WP-CLI command to create the object-cache.php symlink.
- Updates LCache to v0.3.2, which is more noisy about failed L2 serialization.
- Better admin notices: alerts when LCache database tables are missing, or if the plugin is active but
object-cache.php is missing.
0.2.2 (September 14th, 2016)
- Updates LCache to v0.3.1, which has L2 cache guard against returning failed unserializations.
- Sets
STRICT_ALL_TABLES on the database handler to fail and give warnings if there are issues with database inserts.
- Bug fix: Uses
LONGBLOB column type for lcache_event value column. Previously, the value column was BLOB which meant that long cache values (e.g. alloptions) could be unexpectedly truncated.
0.2.1 (September 14th, 2016)
- Bug fix: Properly flushes entire LCache with
wp_cache_flush() is called. Previously, LCache was called improperly, meaning none of the cache was flushed.
0.2.0 (September 14th, 2016)
- Updates LCache to v0.3.0, fixing issues with faulty expiration.
0.1.0 (September 7th, 2016)
