You know… There’s one other thing I’ve recently discovered was a massive slow down on client sites I’m hosting.
Now you might think… “How can DNS make any difference? Because after first request to any site, all future requests should come from cached memory.”
That’s what I though… because I was assuming DNS was working.
DNS works fine, unless you use a systemd (yuck) based Distro, which means almost every Linux Distro in common use.
The problem is when many DNS looks have to be made, even site self references.
The default DNS resolver for systemd is a horrible excuse for code, systemd-resolved that is monumentally broken.
Disable systemd-resolved + purge all related packages off your system, so there’s nary a trace of this code remaining.
Start dnsmasq to listen on 127.0.0.1 + 127.0.0.53 (2nd IP cures other systemd madness).
This small change has fixed many problems building + serving the first HTML component.
If you try this + your problems magically are fixed, be sure + update this thread + mention your success.
Changing MySQL from 127.0.0.1 to localhost will roughly double your database throughput, so if database i/o is contributing to slow site speed, this will certainly help.
Another recent problem I uncovered was a PHP Opcache bug (issue still open) + a WP Super Cache bug (issue still open).
Since you’re already using NGINX, this means you’re also using FPM, so setup FPM access logging.
Then run a load test against your site. If your NGINX caching is working correctly (cached content serving), then you should only see PHP involved the first time your code runs…
So if you issue a test of 1000 requests against your WordPress site, if NGINX + WordPress caching is working correctly, your FPM access log should be quiet (no PHP involvement).
If you see 1000 requests flow through to your FPM access log, then PHP is running for every request, which will be a serious performance killer.
Be sure to check this also.