Redis Cache By Xon 2.18.7

[Matt C.]

View attachment 327614

Yes I'm aware 2.18.5 is the latest. Could of worded that better, sorry.

@Xon, your site's download has 2.18.4 as the latest, even though 2.18.5 is selected. Just tested. XF.com's has 2.18.5. I kept downloading the last update from Atelier.

 

[Xon]

@Xon, your site's download has 2.18.4 as the latest, even though 2.18.5 is selected. Just tested. XF.com's has 2.18.5. I kept downloading the last update from Atelier.

I had attached 2.18.4 instead of 2.18.5 for the XF2.3 version on my site. This has been fixed

The fix between 2.18.4 => 2.18.5 is;

• Fix caching forum totals support when a date limit filter or 'Thread list date limit' is set on the forum

 

[Xon]

Xon updated Redis Cache By Xon with a new update entry:

2.18.6 - Bugfix update

• Fix possible incorrect query generation when caching forum totals with custom 3rd party time-conditions

Read the rest of this update entry...

 

[CL4Y]

Hello, when I activate the plugin, Enhanced Search stops working immediately. Is this normal?

 

[Xon]

Given this add-on doesn't touch any search related functionality; yes that is very much unexpected and very likely not due to this add-on

 

[duderuud]

Indeed. Has nothing to do with ES. ES works fine here after updating the Redis add-on.

 

[Ridemonkey]

If Redis is unavailable, will this add-on cause XF to gracefully fail back to a non-cached state, or will the site become unavailable?

My experience is that the stock Redis implementation causes the site to return 500 errors if the cache layer goes away, even if a timeout is set.

 

[Xon]

None of the cache backends will fail gracefully

 

[Can]

I set up a VDS with DirectAdmin, then immediately installed Redis and activated this plugin for XenForo. It’s truly a lifesaver—thank you again!

 

[CL4Y]

Given this add-on doesn't touch any search related functionality; yes that is very much unexpected and very likely not due to this add-on

I see. To be honest, when I set up the redis and enabled advanced search, the instant search wasn't working, but I didn't do a detailed investigation; I'm testing it in a test environment. I'll set up a test environment again and test it.

 

[Can]

There are two separate XenForo forums installed on the same server. If the Redis add-on is active on both of them, will any problems occur?

 

[briansol]

set the namespace uniquely

Post in thread 'Redis Cache By Xon'

Oct 14, 2024

Quick question:

I have two XenForo boards on the same server (different domains and db of course), for both I'm planning to use the following config:

$config['cache']['enabled'] = true;
$config['cache']['provider'] = 'SV\RedisCache\Redis';
$config['cache']['namespace'] = 'instanceX_';
$config['cache']['config'] = [
    'server' => 'localhost',
    'port' => 6379,
    'password' => 'password',
];

Is it enough when I configure different namespaces or would you recommend a different approach?

Thanks!

• FUX Gaming

 

[Can]

Hello everyone,
I have a server running AlmaLinux 10 + DirectAdmin + LiteSpeed.I’ve configured Redis to be used by both WordPress and XenForo, but I want to clarify a few details about the setup. Here’s an overview of my current configuration:

✔ REDIS SETUP ON THE SERVER (DirectAdmin User-Based Redis)​

There is no system-wide Redis installed on the server.
DirectAdmin creates a localized (user-based) Redis instance for each user.
Mine runs through this socket:

/home/admin/.redis/redis.sock

So I’m using a Unix socket instead of a port.
This Redis instance works without issues, and both XenForo and WordPress connect through the same socket.

✔ PHP SIDE (phpredis) STATUS​

To use Redis, the phpredis extension must be active on the PHP side.

• PHP 8.4 has phpredis enabled → working without issues
• LiteSpeed is also using PHP 8.4, so WordPress connects properly
• XenForo shows “phpredis 6.3.0” in the Redis information panel

In other words, phpredis is active for both WordPress and XenForo.

✔ XENFORO CONFIGURATION​

I’m using the RedisCache add-on.
My config is:

$config['cache']['provider'] = 'SV\RedisCache\Redis';
$config['cache']['config'] = [
'server' => 'unix:///home/admin/.redis/redis.sock',
'port' => null,
];
$config['cache']['namespace'] = 'xf_';


$config['pageCache']['enabled'] = true;
$config['pageCache']['lifetime'] = 300;

The XenForo Redis Information page is fully populated:

• Redis 8.2.3
• phpredis 6.3.0
• Memory / TTL / IOPS metrics look normal

So XenForo is fully using Redis.

✔ WORDPRESS CONFIGURATION​

I have LiteSpeed Cache installed, but I disabled LiteSpeed’s built-in Object Cache.
Instead, I’m using Redis Object Cache (drop-in).

• Status: Connected
• Drop-in: Valid
• Metrics page shows activity
• phpredis client active
• Redis → Reachable

So WordPress is also fully working on Redis.

✔ WHAT I WANT TO CONFIRM​

Both WordPress and XenForo are using the same Redis socket and the same phpredis extension.

Current working structure:

• Redis Server: DirectAdmin’s per-user Redis instance
• Connection: Unix socket
• PHP Client: phpredis
• Caching:
  • WordPress → Redis Object Cache plugin
  • XenForo → SV RedisCache add-on
• LiteSpeed Object Cache: Disabled (to prevent conflicts)

Is this architecture correct?
Would using the same Redis instance for both WordPress and XenForo cause any issues in the long run?

To avoid key collisions, I set namespace = xf_ in XenForo.
WordPress already uses its own prefixes.

If necessary, I can move XenForo to a separate Redis database (DB 1), but for now I don’t see any key conflicts.

✔ TL;DR​

• Redis working ✔
• phpredis active ✔
• WordPress Redis Object Cache working ✔
• XenForo Redis Cache working ✔
• LiteSpeed Object Cache disabled ✔
• Both apps using a shared Redis instance via Unix socket ✔

Is there anything in this setup that could cause conflicts, performance issues, or that goes against best practices?
I’d appreciate insights from users with experience.

 

[Xon]

Xon updated Redis Cache By Xon with a new update entry:

2.18.7 - Bugfix update

• Fix incorrect order of applying TLS options for a connection and using redis password authentication when not using phpredis extension
• Fix dragonflydb support when displaying redis stats block around memory usage
  • Note; full dragonflydb functionality has not been tested

Read the rest of this update entry...

 

[Ivancas]

@Xon can you please advise why Redis is displaying the username of other user on the navbar and when you click on it the popup shows the right username?


I've hidden part of the usernames for privacy reasons

 

[Xon]

@Xon can you please advise why Redis is displaying the username of other user on the navbar and when you click on it the popup shows the right username?

That is nothing todo with this add-on, you have some sort of webserver side caching which isn't aware of who is logged in.

 

[bzcomputers]

Been using this add-on for quite awhile now, but I just came across what I would consider a major bug or oversight. All Redis code should be written to gracefully fallback to database, in-memory, or file-based data. This add-on failed hard for me when Redis was down, it appeared to make 3 attempts at pulling a key then gave a fatal error.

Fatal error: Uncaught CredisException: Connection to Redis tcp://127.0.0.1:6379 failed after 3 failures.Last Error : (1) Connection refused ...[B]community/src/addons/SV/RedisCache/Credis/Client.php[/B] on line 607

Is there something that can be done here?

I wouldn't have come across the issue until I had a server have some issues which caused Redis to go down and the site running XenForo and this add-on immediately went down with Redis.

 

[Xon]

All of XF's caching adaptors hard-fail if they have connectivity issues. Redis offers some improved uptime options but individual redis instances shouldn't be dieing.

 

[bzcomputers]

...individual redis instances shouldn't be dieing.

Agreed but my host was (actually still is) having system wide issues on numerous servers involving some enhanced security add-ons causing some instability at times, resulting in Redis reporting OOM and not auto-restarting when it normally should. Just something out of my control, but it did bring to my attention this issue. Which now appears to be a fundamental issue with XenForo's implementation of Redis.

Am I wrong to think that XenForo should fail gracefully when Redis is down, isn't available, etc.? I just can't think of any code I've ever written that interacted with Redis that didn't fail gracefully if Redis wasn't available. To me this isn't convenience but minimal necessity for any Redis coding. This just seems almost obsurd that this is an actually issue that still exists within XenForo.

 

[briansol]

I think this would be on XF to redesign the way they do caching, not this add-on.

if it can't pull from the cache after a retry, it should compute/pull direct and send an alert of some sort "Hey admin, cache hit failed at X time".