Hi all,
Here’s my test -
I’m just curious why the first byte time is so high on the first run, CPU utilisation is zero during this time so I’m clueless to what’s causing the delay.
Caching has kicked in from the second run and I’m very happy with the results, but would be nice to get to the bottom of that delay.
Running NginX / PHP-FPM on a Kimsufi KS-1 server
Thanks for looking
Time to serve first asset relates to…
Hosting environment.
Code you’re running.
Since you’re running WordPress the optimization process is fairly simple.
You say you’re running NGINX + likely your running NGINX → Apache → FPM.
Likely problem is your WordPress caching. Currently WP Super Cache is broken + W3TC is always slow.
Try setting up WP Fastest Cache + likely this will help some.
And… how your hosting (runtime environment) is setup has a huge amount to do with your site speed.
You’re running on OVH SAS, which likely means some sort of cloud services. If this setup uses software VMs, then this may be the problem… as VMs dramatically decrease performance.
If you have ssh access, run mysqltuner + ensure your database is optimized for speed (so fix all emitted diagnostics).
Since you’re running FPM, setup your config to emit the normal access.log file + you can likely seem immediately where the slowness comes from.
Thanks for the response
Mysqltuner has given me a lot to think about and only time will tell if its suggested tweaks will make a difference.
Nginx + php-fpm is the sole webserver, no Apache involved. The server is dedicated, not VPS, though it is very low spec. I have caching set up on Nginx which works very well after the TTFB problem on the first run, I’ll look at the Wordpress plugins if I can’t make a big difference with other tweaks.
Things seem to be going well!!
I’d like to think that MySQL tuning has had the biggest difference, but another change I made was to point Wordpress to 127.0.0.1 for the database rather than localhost. I think that’s made the biggest difference.
Changing 127.0.0.1 to localhost has so tiny difference in your case that you really shouldn’t even think about it unless your WP executes dozens of thousands of SQL queries.
Most probably you have caching plugin installed (W3TC or something similar) or your web server is caching your pages on per URL basis. On first visit you hit empty cache and PHP code has to be run on your server which results in 1.0+ sec response times. On subsequent requests the cache for this URL is already populated and it’s a basically matter of sending back static content to the user browser.
You can easily verify that. Check response times for:
http://randomthoughts.trisect.uk/?t=3
(alter the “3” at the end). You will notice that the first request takes 1.0sec+ time to complete and next requests to that URL require substantially less time to complete. Then change the URL parameter again to notice that the first request again requires 1.0sec+.
You know… There’s one other thing I’ve recently discovered was a massive slow down on client sites I’m hosting.
Local DNS.
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.
To fix…
Install dnsmasq.
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.
[hr]
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.
Performance is always poor first time through: you have to prime all of the caches as well as deliver the code. If it wasn’t slow, you wouldn’t need to do all of this caching!
A few comments:
if you want to speed up MySQL, then use the tuner scripts available on the net. Remember that - even though you have a dedicated server - disk access is the killer of performance. Bung in more memory and use that wherever you can. MySQL usually uses little CPU if it can deliver from caches
if you want to speed up access to MySQL , then don’t fart about with IP addresses: dump the whole TCP stack and just access it via a socket. Usually it’s something like /var/lib/mysql/mysql.sock, so you add
define(‘DB_HOST’, ‘:/var/lib/mysql/mysql.sock’);
in wp-config.php.
DNSMASQ does far more than just providing DNS, and things like DHCP are really unwanted on a server. Just install a BIND caching server - there are plenty examples on the net. I’d ensure ports 53/TCP and 53/UDP are blocked from the net though.
Don’t forget to tune PHP - and use the latest version that you can: 7.0 or even 7.1 if possible. Tune the Zend Optimiser and possibly even look at using the APCu Opcacher. ALso ensure there’s plenty of memory allocated to share stuff within FPM. I now use ondemand mode and tend to overallocate memory / workers: the important thing is to keep the timeouts as low as you can.
You have many caches available in nginx too: open file and fastcgi are 2 you may want to play with. Also, use http2!
Thanks for all the responses
DNS has always been provided by Named, and on my original test I shared the link to that was fast, it was the http request that was slowing things down.
I’m now doing PHP opcode caching, Wordpress is connecting to MariaDB via socket, and test results seem to be fairly uniform irrispective of when they’re done, so I think I’m where I need to be now. Much still to learn about this caching and it will take me time to get everything right, but I think my site’s consistently fast enough now.
did u find the solution ?
we keep getting F for first time byte and we optimized the whole application and website.
we need to figure out the main issue here . please help
this is the website gooneworld.com
No problems here, what WPT location are you testing it from?
You might want to start your own thread to discuss any optimisations