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

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

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, 1 week ago by Vimal Roy.
• This reply was modified 1 month, 1 week ago by Vimal Roy.

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 @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

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.

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

Hi @antonvlasenko ,

Thank you for your response and for confirming the indexing type.

I appreciate your caution about the plugin and the potential risks with removing existing indexes. We’ll make sure to back up the database and test any changes in a staging environment before applying them to the live site. Your suggestion to analyze slow queries and add indexes selectively makes sense, and we’ll consider that approach.

Thanks for your help and the recommendation for finding qualified support. We’ll keep it in mind if needed.

Best regards,
Vimal Roy

Hi @antonvlasenko ,

Thank you for your response and for sharing your insights.

Regarding the suggestion to remove old articles, I understand the rationale behind it, but as a news agency, retaining old articles is crucial for our SEO strategy. These articles are already indexed by search engines and have accumulated backlinks, which significantly contribute to our traffic. Removing them could result in broken URLs, a loss of traffic, and a negative impact on our SEO and rankings. However, we will consider archiving or removing articles that do not have any backlinks or do not contribute to our SEO strategy. Your advice on this is greatly appreciated.

Regarding the indexing of database tables, I came across a plugin called Index WP MySQL For Speed that specifically aims to optimize MySQL indexes for WordPress. I wanted to confirm if this is the type of indexing you were referring to. If not, could you please provide more details on the indexing approach you mentioned?

We are already utilizing WP Rocket for caching and preloading, and we have Redis Object Cache enabled on our server to cache database queries. Despite these optimizations, we are still experiencing performance issues, so any further recommendations you might have, particularly in terms of database optimization, would be greatly appreciated.

Thank you once again for your time and assistance.

Best regards,
Vimal Roy

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

Hello @gripgrip,

I got a solution from the XML Sitemap & Google News plugin support team. The feed check condition needs to be modified, like below.

Instead of using this?

if ( is_feed()) {

Use the below code by modifying that line.

if ( is_feed() && ( ! function_exists( 'is_news' ) || ! is_news() ) ) {

This line of code will fix the mentioned issue.

Thank you ??

Hello @ravanh ,

Thank you for the solution.

This solution worked ??

Thanks again

Hello,

Thank you for the response.

We checked your solution, but unfortunately, it is not working. The news site map still doesn’t display the latest news.?

Do we have a function called is_sitemap() in WordPress? Do you think that will work??

In the meantime I created a function to exclude the sitemap by using its slug, Please check below code.

function wpb_snippet_publish_later_on_feed( $where ) {
    global $wpdb;

    if ( is_feed() && !is_admin() && !is_sitemap_request() ) {
        // Timestamp in WP-format.
        $now = gmdate( 'Y-m-d H:i:s' );

        // Number of units to wait.
        $wait = '20'; // integer.

        // Choose time unit.
        $unit = 'MINUTE'; // MINUTE, HOUR, DAY, WEEK, MONTH, YEAR.

        // Add SQL-syntax to default $where.
        $where .= " AND TIMESTAMPDIFF($unit, $wpdb->posts.post_date_gmt, '$now') > $wait ";
    }

    return $where;
}

add_filter( 'posts_where', 'wpb_snippet_publish_later_on_feed' );

// Function to check if the current request is for a sitemap.
function is_sitemap_request() {
    $request_uri = $_SERVER['REQUEST_URI'];

    // Check for specific sitemap URL
    if ( strpos($request_uri, 'sitemap-news.xml') !== false ) {
        return true;
    }

    return false;
}

Can you please check and make sure it is working fine with the plugin? I tested it on my development site and it is working like the way I mentioned (delay only for feeds and the delay does not affect the sitemaps).

Please check and let me know your thoughts.

Thank you ??

Hello?@bcworkz,

Thank you for the response.

We are also unfamiliar with the issues and don’t know how to fix them. Anyway,?we will research them and try to solve them.

The preview option is also not working because of the different URLs on the WordPress address and site address. We need to check how we can solve such issues while proxying the website through different servers.

Thank you

Hello @bcworkz,

Both are on different servers and domains. So what configuration files do I need to modify? Please give an example, like which file, what configurations, and all. That would be great. The WordPress site is on the Nginx MySQL (LEMP) server.

Thanks in advance!

The issue was fixed by using a classic editor instead of a block editor (installed the classic editor plugin). Now I can create, edit, or update the posts.?

However, can we also use the block editor without any of the issues I mentioned?