Guest Page Caching - Redis vs Cloudflare vs Other?

[bzcomputers]

For those who have tried either Redis Guest Page Caching, Cloudflare Guest Page Caching or another guest page caching solution...

What is your experience?
Much of a performance change?
Have you tried different caching options and found benefits of one solution over another?

 

[MySiteGuy]

Best I've seen is APCu or KeyDB (Redis replacement) but as with all of them if hosted locally the difference between all of them is small enough that it really doesn't matter unless you have a very loaded server. For most people, I say pick whatever is easiest to implement.

Also, you left Xenforo's file system cache off the list.

 

[nodle]

I use a combination of both Cloudflare and Redis. It won't let me select more than one option.

 

[rdn]

CloudFlare Edge caching is the easiest to implement, and I also have a few minutes of caching on the backend using Nginx fastcgi_cache.

 

[Ivancas]

I think Redis caches sessions or queries, which is something CloudFlare can't do

 

[bzcomputers]

I'm interested in trying out KeyDB with it's multi-threaded capabilities. I've been running Redis but the single thread limitation is definitely a bottleneck at times. Adding replication and multiple instances to Redis just seems like a work around for the issue.

@MySiteGuy were you able to get KeyDB to integrate with XenForo pretty easily. I know it isn't supported out of the box and was wondering what I might be in for getting switched over from Redis.

 

[eva2000]

For those who have tried either Redis Guest Page Caching, Cloudflare Guest Page Caching or another guest page caching solution...

What is your experience?
Much of a performance change?
Have you tried different caching options and found benefits of one solution over another?

I have been using Cloudflare guest page caching for myself and my clients nearly 6 years for various web apps including Wordpress and Xenforo + Redis based object caching from Wordpress and Xenforo plugin/addons

Correctly done, it can make a lot of difference for guest based page load times. You can leverage the Cloudflare GraphQL Timings API to measure your TTFB and page load metric performance and even break them down by Cache Status - miss, hit, dynamic. So you can check your guest cached performance vs logged in member (dynamic) performance. Example https://community.cloudflare.com/t/...-byte-ttfb-with-cloudflare/390367/3?u=eva2000

But that is only part of the performance. For non-guest/logged in members, you'd have to optimize the rest of your web stack and server for non-cached request load. I wrote a guide on Cloudflare support forums on how to improve your TTFB times leveraging Cloudflare - including 3 different segments you need to optimize for best performance https://community.cloudflare.com/t/improving-time-to-first-byte-ttfb-with-cloudflare/390367

To fully optimise you need to optimize 3 segments.

segment 1 - connection between visitor and CF edge server i.e. CDN cache/CDN cache control, Cache Rules, WAF, Firewall, Page Rules, Mirage, Polish webP, HTTP/2, HTTP/3, CF Workers (i.e. custom/advanced caching) etc. Cloudflare CDN level caching effectively reduces your origin server resource usage loads for CPU/Memory etc as request load is offloaded to Cloudflare CDN edge servers in an Anycast manner to the closest CF datacenter to the visitor.

segment 2 - connection between CF edge server and your origin i.e. TLSv1.3 origin server support, Argo, Railgun, Full SSL/ECDSA SSL certificates origin served, pre-compressed/dynamically compressed gzip and/or brotli encoded asset served from origin, Tiered Caching and Cache Reserve eventually once out of Beta (right now TTFB ends up slower with Cache Reserve beta enabled).

segment 3 - your origin server’s performance/optimisations i.e. web server, PHP, MySQL server optimisations and server hardware specs. Origin server side caching, PHP Zend Opcache caching, MySQL’s various buffer caching and various other origin server side caching can also be used.

Cloudflare can only help for segments 1 & 2 for cached guest/non-logged based visitors will easily scale. Now for Cloudflare CDN cache miss/bypass and logged in user for web apps like forums/wordpress, performance will be determined by segment 3. Which is the default with Cloudflare as dynamically generated HTML pages aren’t cached by default so cache miss means, whatever performance you have is measuring your origin server’s response time.

Disclaimer: I've been an official Cloudflare community MVP since 2018 - an unpaid position similar to Microsoft MVP, so I get to work more closely with Cloudflare and learn all their products/service offerings. Though I've been a Cloudflare customer for 13+ yrs

I'm interested in trying out KeyDB with it's multi-threaded capabilities. I've been running Redis but the single thread limitation is definitely a bottleneck at times. Adding replication and multiple instances to Redis just seems like a work around for the issue.

Make sure you've configured and squeezed out as much as you can in your Redis configuration as well

I've been using and benchmarking Redis protocol supported alternatives - Redis vs KeyDB vs Dragonfly for months now and liking KeyDB more. Depending on their benchmark performance, I tend to install both Redis and KeyDB and pick either for specific tasks. Sometimes spinning up several instances of each on custom ports. Redis, KeyDB and Dragonfly performance depend on how many CPU cores/threads you have and their configurations.

Example below

memtier benchmark comparing Redis 7.2.3 with default io-threads 1 and 2 vs KeyDB 6.3.4 for 1, 2, 3 and 8 threads (+ raising server-threads from 2 to 4 on 4 CPU core KVM VPS running AlmaLinux 8 with Centmin Mod 130.00beta01 LEMP stack.]

KV Databases	Threads	Sets (ops/sec)	Gets (ops/sec)	Totals (ops/sec)	vs Redis 2 threads Sets	vs Redis 2 threads Gets
KeyDB 6.3.4 server-threads=4	1	9818.99	147284.89	157103.88	0.95x	0.95x
KeyDB 6.3.4 server-threads=4	2	21434.70	321520.53	342955.23	2.07x	2.07x
KeyDB 6.3.4 server-threads=4	3	29326.45	439896.80	469223.26	2.84x	2.84x
KeyDB 6.3.4 server-threads=4	8	23136.90	347053.44	370190.33	2.24x	2.24x
KeyDB 6.3.4 server-threads=2	1	7770.48	116557.14	124327.62	0.75x	0.75x
KeyDB 6.3.4 server-threads=2	2	14650.89	219763.35	234414.24	1.42x	1.42x
KeyDB 6.3.4 server-threads=2	3	16959.49	254392.40	271351.89	1.64x	1.64x
KeyDB 6.3.4 server-threads=2	8	22175.40	332631.04	354806.44	2.14x	2.14x
Redis 7.2.3 io-threads 1	1	7404.66	111069.97	118474.64	-	-
Redis 7.2.3 io-threads 1	2	10338.26	155073.83	165412.08	-	-
Redis 7.2.3 io-threads 1	3	6660.16	99902.42	106562.59	-	-
Redis 7.2.3 io-threads 1	8	10177.75	152666.27	162844.02	-	-
Redis 7.2.3 io-threads 2	1	7886.29	118294.40	126180.69	-	-
Redis 7.2.3 io-threads 2	2	14104.89	211573.37	225678.26	-	-
Redis 7.2.3 io-threads 2	3	13244.12	198661.73	211905.85	-	-
Redis 7.2.3 io-threads 2	8	12750.31	191254.59	204004.90	-	-

 

[Xon]

Best I've seen is APCu or KeyDB (Redis replacement) but as with all of them if hosted locally the difference between all of them is small enough that it really doesn't matter unless you have a very loaded server. For most people, I say pick whatever is easiest to implement.

I've seen APCu deadlock and takeout php-fpm before, and the on the github project for APCu; the developer's response to this issue is 'dead locks happen'

 

[MySiteGuy]

I'm interested in trying out KeyDB with it's multi-threaded capabilities. I've been running Redis but the single thread limitation is definitely a bottleneck at times. Adding replication and multiple instances to Redis just seems like a work around for the issue.

@MySiteGuy were you able to get KeyDB to integrate with XenForo pretty easily. I know it isn't supported out of the box and was wondering what I might be in for getting switched over from Redis.

Its as easy as uninstalling Redis, and install Keydb in it's place.

Keydb uses the same config file syntax, except it's named keydb.conf instead of redis.conf. The Xenforo config file can remain the same (unless you're using sockets instead of the default port settings).