Support Request: Redis Object Cache Plugin – Connection Issues and Errors

I have the same issue… it’s happening way too often.

With a team of 20-30 people you might want to consider using Object Cache Pro instead.

As for read error on connection and 500 errors, that’s your Redis Server not responding in time, are you monitoring Redis Server? What do the CPU charts look like?

I’d need to see Redis logs to tell you which commands are failing and why.

Consider setting these, that might help with timeout:

WP_REDIS_DISABLE_GROUP_FLUSH=true
WP_REDIS_SELECTIVE_FLUSH=false

Hello @tillkruess ,

Thank you for your prompt response and for the suggestions provided.

To clarify, our team includes a mix of authors, editors, and administrators, but only about 7-10 people are actively engaged in creating, translating, editing, and publishing articles at any given time. While we have multiple roles on the site, the actual number of concurrent users performing content-related tasks is smaller, though they are often working simultaneously.

We appreciate the configuration recommendations, specifically the use of:

• WP_REDIS_DISABLE_GROUP_FLUSH=true
• WP_REDIS_SELECTIVE_FLUSH=false

However, we noticed in the Redis Object Cache plugin guide on GitHub that WP_REDIS_SELECTIVE_FLUSH is listed under Unsupported configuration options, with a note that options in this category may break without notice in future releases and won’t receive support from your team.

Our questions are as follows:

1. Stability and Future Compatibility: Given that WP_REDIS_SELECTIVE_FLUSH is marked as unsupported, could you please provide insight into any potential risks associated with adding this constant? Specifically, are there any known stability issues, performance implications, or long-term concerns we should be aware of?
2. Redis Server Monitoring: We understand that the Redis Server not responding in time is a core issue, and we are actively monitoring its performance. However, could you please advise on what specific Redis logs or command failures we should be focusing on to better diagnose and address these connection errors?
3. Object Cache Pro Consideration: We are open to exploring Object Cache Pro if it can provide enhanced stability and performance for our setup. Could you share more details on the expected benefits, particularly in the context of our high-traffic, multilingual environment?

Additionally, we have attached a document containing Redis logs that capture various warnings and errors, including RedisException events that are affecting our site. You can access the logs here. We would appreciate it if you could review these logs and provide any insights or recommendations based on the issues highlighted.

Your guidance on these queries would be invaluable as we work to optimize our Redis setup and mitigate these ongoing performance issues.

Thank you once again for your continued support, and we look forward to your feedback.

Best regards,

Vimal Roy

Correct, WP_REDIS_SELECTIVE_FLUSH is unsupported and off by default, I just wanted to make sure you have it set to false.

As for Redis Server monitoring, there are various tools out there like New Relic and Datadog, if you’re already monitoring your infrastructure with a tool, they might have Redis monitoring as well.

Thanks for the sharing the logs, it’s not enough to go on, since the issue is Redis not responding at all or in time.

Object Cache Pro Consideration: We are open to exploring Object Cache Pro if it can provide enhanced stability and performance for our setup.

That’s exactly what is does, in that order ??

Hello @tillkruess

Thank you for your response and for the clarification.

To confirm, we have set WP_REDIS_SELECTIVE_FLUSH to false in the wp-config.php file as recommended.

Regarding the monitoring tools, we are currently not using New Relic, Datadog, or other specific Redis monitoring tools. While we do monitor the website, server load, and related metrics, we have not implemented any dedicated monitoring for Redis itself.

Upon reviewing yesterday’s logs, we identified two occurrences of 500 errors related to Redis in the access logs. We have cross-referenced these with the corresponding web server error logs and Redis error logs. For your reference, I have shared the details of these errors in the following Google Docs link: View Logs.

Since the previous logs were not sufficient for further analysis, we hope that these newly shared logs provide more clarity on the issues we are experiencing. Please review them and let us know your feedback or any additional recommendations.

If you need anything more or any other specific information/logs, please let me know.

Thank you once again for your continued support.

Best regards,
Vimal Roy

• This reply was modified 2 months, 1 week ago by Vimal Roy.

The errors socket error on read socket and read error on connection are timeouts (or high latency responses).

Can you post the output of redis-cli SLOWLOG GET?

Dear @tillkruess ,

Thank you for your insights on the timeout issues. As requested, I have gathered the output from redis-cli SLOWLOG GET, which you can access through the following link:

View SLOWLOG Output.

Could you please review the logs and provide any further recommendations on how we might reduce or fix these timeout errors? We are particularly interested in understanding if there are any specific Redis configurations or optimizations we could implement to mitigate these socket timeouts and high-latency responses.

Your guidance on resolving this issue would be greatly appreciated, as the timeouts are affecting our website’s stability and performance.

Thank you once again for your continued support.

Best regards,
Vimal Roy

It looks like your FLUSHDB calls are extremely slow. I can’t tell you why, they really shouldn’t be. This would be a question for your devops team.

You can alternatively use Object Cache Pro which has asynchronous flushing. Happy to send over a discount, if it’s too pricy.

Dear Till(@tillkruess ),

Thank you for reviewing the logs and providing your insights. We appreciate the feedback regarding the slow FLUSHDB calls. I will consult with our devops team to investigate why these operations are taking longer than expected.

Regarding Object Cache Pro, we are open to exploring its asynchronous flushing capability if it can help mitigate this issue and improve overall performance. Please do send over the discount details, and we’ll review the pricing to assess whether it fits within our current budget.

Thank you again for your support. We look forward to any further recommendations you may have.

Best regards,
Vimal Roy

Dear Till ( @tillkruess ),

Thank you for your continued support in troubleshooting the Redis timeout issues.

I reached out to our server management team, and they tested the FLUSHDB calls on our staging server. Based on their results, the first call took 2.47 seconds, but subsequent flushes were instantaneous, with no noticeable delay. Here’s a snippet of their testing:

root@coinedition-staging:~# redis-cli
127.0.0.1:6379> FLUSHDB
OK
(2.47s)
127.0.0.1:6379> FLUSHDB
OK
127.0.0.1:6379> FLUSHDB
OK
127.0.0.1:6379> FLUSHDB
OK

Given these findings, they’ve asked if there are any additional or alternative methods to test this further or recreate the slow FLUSHDB calls as we observed on the production environment. Any guidance or suggestions on additional steps we can take to help replicate this issue would be greatly appreciated.

Thank you once again for your assistance, and we look forward to hearing your thoughts on how to proceed.

Best regards,
Vimal Roy

• This reply was modified 1 month ago by Vimal Roy.
• This reply was modified 1 month ago by Vimal Roy.

You can simulate a slow FLUSHDB by filling up your Redis Server with fake keys, try 100k and 1M to see the impact. If you share your email I can get you a Object Cache Pro discount which would resolve this issue for you.

Hello Till( @tillkruess ),

Thank you for the update and the suggestion to simulate the slow FLUSHDB calls. We will proceed with the testing as you mentioned by filling up the Redis server with fake keys and checking the impact.

Regarding Object Cache Pro, here is our email address: [email protected].

We appreciate your continued assistance and look forward to hearing from you regarding the discount.

Best regards,
Vimal Roy

Hello Till(?@tillkruess ),

Thank you for the suggestion regarding simulating slow FLUSHDB calls. We proceeded with the test on our staging server, and while there was no delay with 100k fake keys, the process got stuck when attempting to fill Redis with 1M keys using the following script:

for i in $(seq 1 1000000); do
  redis-cli SET "key:$i" "value for key $i" > /dev/null
done

Would you recommend an alternative way of filling the Redis server with a larger number of fake keys to help us complete the testing?

Looking forward to your feedback.

Best regards,
Vimal Roy