Learn about Centmin Mod LEMP Stack today
Register Now

Benchmarks Optimizing and tuning WordPress and XenForo with NewRelic

Discussion in 'Dedicated server hosting' started by deltahf, Oct 8, 2021.

  1. deltahf

    deltahf Premium Member Premium Member

    576
    259
    63
    Jun 8, 2014
    Ratings:
    +475
    Local Time:
    8:57 PM
    After further investigation, I am still unable to diagnose what caused PHP application processing times to nearly double after upgrading to PHP 8.1.

    I carefully studied and confirmed no configuration changes were present in php.ini or php-fpm.conf. PGO and JIT remained enabled as expected.

    This left me no choice but to downgrade back to PHP 8.0.25 to see what happens, but that is when things get even more strange.

    Downgrading did restore XenForo page generation times back to previous levels, but WordPress times did not change.

    wp vs xf.png

    I also performed additional benchmarks before and after the downgrade with Centminmod's detailed_benchmark.php. Averaging over three runs, it showed no significant difference in speed between the two PHP versions.
    • PHP 8.1: average 1.164s
    • PHP 8.0: average 1.157s
    It should be noted that although the latest version of XenForo (v2.2.12) does seem to work with 8.1 without any serious issues, it is not "officially supported" by the developers and 8.0 is still the "recommended" PHP version. So, that might explain it.

    WordPress is the bigger mystery, and PHP itself might not be the problem. I did update WordPress and some plugins before the 8.1 upgrade, but did not suspect them due to the fact that XenForo was also impacted.

    NewRelic does provide additional WordPress-specific metrics which can be extremely valuable. In this case, I believe they show the most frequently-called and most time-consuming hooks all simply started taking a longer amount of time after the upgrades.

    Screen Shot 2022-12-14 at 4.15.00 PM.png

    We can also look at WordPress plugins:

    Screen Shot 2022-12-14 at 4.15.20 PM.png

    The response times show the most significant slowdown (though we are talking about microseconds there), but like the WordPress core hooks, it seems all of the plugins were affected proportionately — which to me suggests that not one of them in particular is subject to the blame here. It's like they are all suddenly operating in a slower environment.


    BUT if the PHP version is not to blame... what is it?

    I did upgrade from WordPress 6.0 to 6.1.1. There were reportedly many performance improvements in 6.1, but there's always a chance some of them backfired. Of course, if it is just a 6.1 performance problem... why did XenForo slow down as well? Maybe that was just a separate issue?

    My head is spinning.
     
  2. eva2000

    eva2000 Administrator Staff Member

    52,010
    11,978
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +18,475
    Local Time:
    10:57 AM
    Nginx 1.25.x
    MariaDB 10.x
    Weird indeed. Have you tried PHP 8.0 vs 8.0 with Profile Guided Optimizations (PGO) disabled?

    Also try after updating to Wordpress 6.1, did you recompile PHP with PGO enabled - especially if you're setting PHPPGO_INDEXPATH in persistent config file at /etc/centminmod/custom_config.inc to Wordpress index file as you're telling PHP recompile with PGO enabled to also do PGO training against Wordpress index file and that would of changed between Wordpress 6.0 and 6.1 update
     
  3. deltahf

    deltahf Premium Member Premium Member

    576
    259
    63
    Jun 8, 2014
    Ratings:
    +475
    Local Time:
    8:57 PM
    Ah, this is very interesting and makes a lot of sense. I will definitely keep this in mind, but I think I'm sticking with 8.0 for now due to XenForo's performance issues.

    Anyway, I think I figured it out!

    Check out these graphs after 5:00pm, when I started an experiment. :eek:

    Screen Shot 2022-12-14 at 11.22.53 PM.png

    Screen Shot 2022-12-14 at 11.23.49 PM.png

    Screen Shot 2022-12-14 at 11.24.00 PM.png

    All I did was simply disable WooCommerce.

    The only thing that was really standing out to me in the graphs were those 200k+ per minute WooCommerce function calls, so I started to get suspicious and decided to run an experiment. Disabling WooCommerce has made the numbers more stable and maybe even slightly lower than before this whole situation began, still on 8.0!

    As I documented previously in this thread, last year I did some tests enabling/disabling WooCommerce. It's a well-known performance slog, but my tests at the time showed it really wasn't doing that much harm. I have a small store and heavily optimized my custom theme with WooCommerce in mind so I thought that helped.

    However, WooCommerce was also one of the plugins I updated during my big round of upgrades a few days ago, and apparently, whatever they have done in this latest update is having a serious impact on performance.

    WooCommerce seems to be one of those plugins where the authors just assume that if you're running it, that's the only thing you're using your site for. It just takes over your whole WordPress install and expects you will be running an ecommerce store, not a blog. But, even if I wasn't running a blog, these performance numbers for a store are just not acceptable. I am running a highly optimized site (in my opinion) on a powerful dedicated server with the best software in the business (Centminmod!). If WooCommerce is this slow for me, I can't imagine how poorly it must be running for other people! But I digress.

    At this point I have to figure out what to do. My store makes up an extremely small part of my business, and maintaining it and integrating it with the rest of my site's custom WP theme has always been a headache. It would be nice, for so many reasons, to just close the store and drop it, and I'm considering that.

    The other option would be to keep running it and rely on the various caching layers to work their magic, but I really don't like that uncached, first-hit performance. I am seeing TTFB times on uncached tag and category pages of over 1 second, which is not acceptable.

    Other than that, I'm not sure what to do. I suppose I could run two WP installs on my site, one for my blog on the site root, and the other in a subdirectory for the store. But that sounds like a big maintenance headache.

    I have some thinking to do.
     
  4. eva2000

    eva2000 Administrator Staff Member

    52,010
    11,978
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +18,475
    Local Time:
    10:57 AM
    Nginx 1.25.x
    MariaDB 10.x
    Yeah WooCommerce is a known performance hog and needs more tweaking and tuning as the data set in the database tables grows. I've avoided WooCommerce myself for similar adventures I was planning. From my research EDD is better Easy Digital Downloads – Simple eCommerce for Selling Digital Files though really haven't had time to dig into them myself.