/ Register

Want to subscribe to topics you're interested in?
Become a Member

How to Diagnose High TTFB?

Discussion in 'System Administration' started by KlueMaster, Feb 17, 2022.

Previous Thread Next Thread
Loading...
  1. Feb 17, 2022 #1
    KlueMaster

    KlueMaster Member

    62
    11
    8
    Aug 5, 2017
    Ratings:
    +26
    Local Time:
    3:36 AM
    MariaDB 10
    I've started getting a very high TTFB on my WordPress/WooCommerce site on CMM beta branch, specially for logged in users.

    The TTFB is now typically between 4-8 secs. as compared to around 0.5 second earlier. I'm not able to figure out the reason for the same. There are no errors logged, neither in WooCommerce status logs, nor in site error log.

    Could someone please help me with diagnosing and resolving this?
     
  2. Feb 17, 2022 #2
    cloud9

    cloud9 Premium Member Premium Member

    310
    85
    28
    Oct 6, 2015
    England
    Ratings:
    +146
    Local Time:
    11:06 PM
    1.21.5
    10.3.32
  3. Feb 17, 2022 #3
    tininho

    tininho Active Member

    177
    39
    28
    May 22, 2019
    Ratings:
    +128
    Local Time:
    1:06 AM
    That is very high jump, what is your caching solution? WP Rocket can cache Woocommerce for logged in users as well, so can Centminmod with Fastcgi cache, when you configure it properly (uncomment some lines in php configuration, if you have not changed default Woocommerce paths etc).

    The obvious question would be what has changed in between?
     
  4. Feb 18, 2022 #4
    eva2000

    eva2000 Administrator Staff Member

    49,039
    11,235
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +17,487
    Local Time:
    8:06 AM
    Nginx 1.21.x
    MariaDB 10.x
    Pretty sure the problem would be Woocommerce related as you can't cache those related requests so ultimately response times need to hit your backend Nginx/PHP-FPM/MariaDB MySQL config and that needs to be optimized in itself.

    Centmin Mod initial install auto optimizes the Nginx/PHP-FPM/MariaDB settings based on detected server environment, CPU, memory and disk performance. But that only optimizes settings for the server. You then need to optimize your configuration for the web app usage requirements which is an entirely different set of optimizations you'd be responsible in doing yourself or hiring someone to do for you.

    90% of the time slow server response time (high Time To First Byte - TTFB), is related to slow backend MySQL queries causing PHP to wait for a while to get a response from MySQL. This in turn leads to Nginx waiting for PHP to respond. So you have to work backwards and first look at your slow MySQL queries and see what PHP code/plugin it is related to and optimize the slow queries and/or try with such Wordpress plugins disabled and retest/profile for MySQL slow queries and see if you can narrow down where they're coming from.

    I just finished several weeks worth of paid client Xenforo forum server optimization work with several clients for this very problem with high average TTFB in 1.5-15s. After optimization, their Xenforo forums are back down to an average 0.3-0.55 TTFBs :D My paid server optimization consults is what I have been doing for past 10+ yrs and is my day job which pays my bills (and bills for Centmin Mod related running costs) and usually starts in the low 4 figure $$$$ BTW.

    It usually isn't just MySQL in isolation but Nginx and PHP and maybe system/server settings needing optimizing to account for slow MySQL queries. So the below CPU load and PHP-FPM troubleshooting guides are also applicable in investigating the issue and coming up with a solution.
     
  5. Feb 20, 2022 #5
    deltahf

    deltahf Premium Member Premium Member

    534
    234
    43
    Jun 8, 2014
    Ratings:
    +428
    Local Time:
    6:06 PM
    @KlueMaster, check out my thread documenting my journey of optimizing my WordPress/XenForo site TTFB here:

    https://community.centminmod.com/th...ng-wordpress-and-xenforo-with-newrelic.22047/

    I would bet good money that, if this is a sudden issue, it's plugin's faulty update. The "easy" but less scientific way to diagnose would be to enable/disable plugins one-by-one and see if you can find the guilty party.

    My recommendation, however, would be to install NewRelic's PHP APM on the server. I'm actually surprised this isn't more widely talked about in the WordPress world, but in my opinion, NewRelic's WordPress-specific monitoring capabilities are nothing short of incredible and a must-use for anyone concerned about WordPress performance.

    Kinsta has an article on this here:

    How to Find WordPress Performance Bottlenecks with New Relic

    It gives you a plugin-by-plugin, hook-by-hook, and page-by-page breakdown of page loading times and exactly what is contributing to the overall execution time. It's like having x-ray vision into your WordPress install. As you can see in my post here, I was able to immediately identify a single non-essential plugin that was adding an average of 175ms of processing to my page load times.

    NewRelic can be kind of tricky to install, but if you are willing to push through it I think it will be worth your time, solving this issue and any other problems that crop up in the future!
     
  6. Feb 20, 2022 #6
    eva2000

    eva2000 Administrator Staff Member

    49,039
    11,235
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +17,487
    Local Time:
    8:06 AM
    Nginx 1.21.x
    MariaDB 10.x
    +1 Yeah NewRelic is nice though any tool is only as good as the person using it and their understanding of what the tool is reporting :)
     
Previous Thread Next Thread
Loading...

.