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.

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.

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+.

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.

Like help speeding up your site? Skype me @ ID davidfavor for a quote. Be sure to include your site name in your Skype Add Contact request.

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!

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