Optimize RankMath Codebase for Huge Websites

#605220
  • Resolved Saumya Majumder
    Rank Math free

    Hi guys,
    Hope you guys are doing well. I’m opening this ticket on behalf of one of my clients. So, here’s the situation:

    Currently, we have observed that the RankMath plugin performs optimally on small to medium-sized websites. However, its performance significantly deteriorates when deployed on super-large sites, leading to various issues. I would like to bring one major concern to your attention, which is causing severe disruptions despite being hosted on a robust dedicated server boasting 64 Cores, 128GB memory, and NVMe drives.

    The primary culprit appears to be within the “/seo-by-rank-math/includes/modules/sitemap/providers/class-post-type.php” file, specifically at Line No. 364. This section of code is responsible for generating the list of posts in the sitemap.

    Consider the scenario of a website with a staggering post count of 348,438+. As you can imagine, such a database size can lead to substantial performance challenges. When the SQL query from the aforementioned PHP file is executed in this context, it exerts excessive strain on the server’s CPU, resulting in throttling and eventual downtime.

    This is a critical issue that is significantly impacting the performance of super-large sites. While I understand that reproducing this problem may be challenging on small to medium-sized websites, it is readily apparent on larger-scale sites.

    I kindly request the development team’s focused attention on this matter. It is imperative that we thoroughly analyze the codebase and optimize the SQL queries to ensure RankMath operates efficiently even on websites with an extensive post database, without imposing undue strain on server resources.

    If you need any additional details please let me know.

Viewing 5 replies - 1 through 5 (of 5 total)
  • Hello,

    Thank you for contacting us, and sorry for any inconvenience that may have been caused.

    The code you mentioned is used to add posts to the sitemap, based on the limit set in the Links Per Sitemap option.

    On your site, each post sitemap contains 10,000 posts. This is why it takes time to load, as the code runs a query to retrieve 10,000 posts and search for images in the content. The code only includes the necessary code and we have also used a custom SQL query because it executes faster compared to WP_Query. I suggest reducing the number to 200-500.

    I hope this helps.

    Hi @pratik-d,
    Actually, you misunderstood my message. The site earlier had 200 items per sitemap which was causing the issue. The reason behind that was as the site has a huge number of posts (348,438+), as a result, if you device that number by 200 (348438/200 = 1742.19), so behind the scene almost 1742 PHP workers are getting generated all executing the same SQL query to get the data. On top of that the website also has visitors so there’s that load.

    You guys really need to look at that SQL query to figure out a way to optimize it.

    Anyways, during my research what I’ve found is if I increase the limit to a large number like 10,000 the SQL server is taking the almost exact same time to execute that SQL query compared to 200 or 500. So, there’s no loss in resource usage in any way.

    Also by increasing the Limit to 10,000 the number of PHP processes are significantly reduced. (348438/10000 = 34.8438) – so instead of running 1742 PHP processes each of which is executing that SQL query, now only 34 PHP processes are needed.

    As both Google and Bing support sitemaps with up to 50,000 loc item in them, so 10,000 is within that very limit. But after increasing the Limit we can see some significant improvement on the website as the number of PHP processes are reduced. This is a band-aid fix for now so the client site doesn’t go down.

    That being said, you guys should definitely look at improving the performance of sitemap generation so that it doesn’t consume a crazy amount of resources for super-large websites (both in terms of DB resource, PHP resource and server resource).

    Do let me know if you have any further questions.

    Hello,

    Thank you for your patience.

    Our developers are discussing this internally to improve the query, and the best approach to possibly include this in the future.

    Meanwhile, you can increase the links per sitemap as you have mentioned for a temporary alternative while we look for a solution to fix the issue.

    If you have any other concerns, please don’t hesitate to contact us anytime to assist you further.

    Looking forward to helping you.

    Thank you.

    Hi,
    That is great to hear. Please let me know when a fix is implemented so that I can test according.
    The trick of increasing the number of items per sitemap is now working great, so for now the band-aid fix is working. I would love to know what the devs come up with after the discussions.

    Hi there,

    Thank you for your positive feedback. We are glad to hear that the temporary solution of increasing the number of items per sitemap is working well for you. We appreciate your patience and understanding as we work on a permanent fix for the issue.

    We will keep you updated on the progress of our development team and let you know as soon as a fix is implemented. You can also check our changelog page for the latest updates: https://rankmath.com/changelog/

    Please feel free to contact us anytime if you have any other questions or concerns. We are always happy to help. Have a wonderful day!

    Hello,

    Since we did not hear back from you for 15 days, we are assuming that you found the solution. We are closing this support ticket.

    If you still need assistance or any other help, please feel free to open a new support ticket, and we will be more than happy to assist.

    Thank you.

Viewing 5 replies - 1 through 5 (of 5 total)

The ticket ‘Optimize RankMath Codebase for Huge Websites’ is closed to new replies.