Deprecate Redis as a Cache Backend

[dtdesign]

Historically we added support for Memcached to support running the software across multiple web nodes and to improve the cache latency for sites running on spinning rust. Some point later we added Redis as an alternative backend with the ability to offload the user storage to Redis too. While Memcached was phased out at some point in favor of Redis, it still remains the only supported alternative to the file based cache.

Changes since the Introduction of Redis

Over the years there have been multiple changes that impacted the usefulness of Redis in our setup:

• Running the software on multiple PHP nodes has always been broken to some extent and the advancements in core density, frequency and IPC of CPUs these days make this an needless and largely unsupported principle.
• Redis is only available for customers running the software on an own (virtual) server. Customers on pure web hosting accounts do not have access to Redis in general and are not impacted at all.
• Spinning rust is rarely being used these days apart from pure capacity storage, in particular among customers running (virtual) servers.
• Filesystems have evolved to provide some proper and consistent in-memory caching, especially ZFS is among those that provide superior performance here.
• MySQL has gotten a lot better over the years, especially 8.0 was a significant upgrade over previous versions.
• The increased usage of the user storage for multiple users scales poorly with Redis due to the sequential nature of the fetch operation. We could implement MGET to achieve similar performance characteristics as a SQL query though.
• The version 2 of the disk cache introduced with WoltLab Suite 6.0 makes use of OPcache to greatly reduce the latency, making the performance less reliant on the filesystem cache.

Performance Evaluation

We have traditionally been running Memcached – and later Redis – on woltlab.com for the purpose of dogfooding this cache backend; Development primarily takes place using the disk cache to cover this aspect too. The WoltLab Cloud had been running on disk cache from the beginning because we’re using ZFS with a big ARC running on top of SSDs, yielding excellent performance numbers. This has proven to hold up over the years even during activity speaks.

In preparation of this issue we have moved woltlab.com off Redis for some time and monitored the both the system load and the PHP metrics through Tideways to see how much the difference really is. The result was a near 5% improvement in the P95 latency. To be fair, some of it could be clawed back by utilizing MGET for the user storage access but since the average time spent interrogating Redis was around 5ms so there is not much to win here.

Roadmap

Maintaining support for Redis is a tedious task that requires on-going testing methods. The offloading in the UserStorage requires us to maintain two different code paths for an important component in the software. There exists an extra code path to gracefully fall back to the disk cache backend when Redis is unavailable.

The performance benefits for the purposes we have been using Redis aren’t there anymore and in some cases it’s even worse for our purposes. We plan to therefore deprecate and remove Redis as a cache backend, eventually hardwiring the disk cache as the only cache backend.

• [x] WoltLab Suite 6.2: Mark “Redis” as deprecated and recommend the use of the disk cache.
• [ ] WoltLab Suite 6.3: Remove “Redis” as a cache backend and remove the handling in the UserStorage.
• [ ] WoltLab Suite 6.3 (?): Remove support for any other cache backends and hardwire the disk cache as the only source.

[dtdesign]

@SoftCreatR @xopez Please feel free to voice your opinion if you think we’ve overlooked something here? These days the Redis cache backend offers no measurable performance improvement while increasing complexity. I would argue that for in most cases the performance is even worse since the v2 of the disk cache was introduced.

The point of “Discussion” type of issues is to gather feedback, so by all means your comment is more than welcome.

[dtdesign]

@syntafin You are also more than welcome to express any concerns you have. Is there anything we may have overlooked?

[syntafin]

The reason is already described in the initial post:

• Redis is only available for customers running the software on an own (virtual) server. Customers on pure web hosting accounts do not have access to Redis in general and are not impacted at all.

Replace Redis with ZFS, what is described as the "modern filesystems".

• Filesystems have evolved to provide some proper and consistent in-memory caching, especially ZFS is among those that provide superior performance here.

Common Webspace don't use ZFS, they run on "old" filesystems Like ext4 or even NTFS (Windows is still a thing).

For me it's sounds like a "we don't need it ourselves, let's remove it for everyone" decision. I know it is hard to maintain a lot of features. The called performance improvements in MySQL may are a good point, but in my own tests, I still see a big performance improvement between queries made to MySQL and such that use Redis as source for their data. (We talk about "normal queries, on MySQL, reduced the time from 1,4ms to 0,2ms)

Memory is still faster then NVMe Storage, and NVMe storage is not the default in the typical Webspace most ppl use out there (normal SATA-SSDs are most used there)

[dtdesign]

Maybe my phrasing was poor, but it appears that there is a misunderstanding here.

1. On a typical webspace account you do not have access to Redis at all and use the disk cache anyway.
2. The disk cache v2 introduced in 6.0 was designed to take advantage of OPcache which itself is stored in memory. Ideally the file system is only checked for meta data.
3. The performance benefit of storing the user storage in MySQL rather than Redis is negligible because those are straight index lookups. The insert/update performance of Redis is superior, but the user storage is a read-intensive persistent cache.

For a webspace customer nothing changes, because Redis never was an alternative for them due to being generally unavailable. This only impacts customers running the software on an own (virtualized) server and for these the performance improvement just isn’t there anymore.