Happy to announce the latest and greatest of WP LCache, [v0.5.0](https://github.com/lcache/wp-lcache/releases/tag/v0.5.0).
This release focuses predominantly on splitting WordPress’ alloptions cache into separate cache keys to mitigate cache pollution caused by race conditions. [Read #31245](https://core.trac.wordpress.org/ticket/31245) for all of the gory details. Thanks to [Ryan](https://twitter.com/rmccue) and [Joe](https://twitter.com/joe_hoyle) for paving the way.
If you haven’t thought about WP LCache since the [v0.1.0 announcement](https://handbuilt.co/2016/09/08/introducing-wp-lcache-v0-1-0/), you’re missing out. WP LCache is faster than other object cache implementations because:
* By using APCu, which is in-memory, WP LCache uses the fastest possible persistent object cache backend and avoids costly network connections on every request. When using a Memcached or Redis-based persistent object cache where Memcached or Redis is on a different machine, the millisecond cost of each cache hit can add up to seconds of network transactions on every request.
* By incorporating a common L2 cache, WP LCache synchronizes cache data between multiple web nodes. Cache updates or deletes on one node are then applied to all other nodes. Without this synchronization behavior, APCu can’t be used in server configurations with multiple web nodes because the cache pool is local to the machine.
Still not convinced? WP LCache has a variety of features no one else has, including native handling of cache groups, meaning you can delete an entire group of keys with `wp_cache_delete_group( $group );`.
Props again to [David Strauss](https://twitter.com/davidstrauss) for his ongoing work on the LCache library, and to [Pantheon](https://pantheon.io/) for sponsoring open source infrastructure.
Install, activate and enable with `wp plugin install –activate wp-lcache && wp lcache enable`.