Not sure what it is but here is a connection to a vbulletin forum - big fat F:
And here is a front page, Wordpress gets a B:
But this wordpress blog gets an F, same install, different front page:
Not sure how to explain the difference and what to do.
So I’ve looked through all of these threads and I cannot explain how first byte time is 1300+ ms. The server is fast and uses SSD. I’m only generating simple wordpress pages and the time is still 1300ms or more, no matter how simple the template. What is going on here?
I can’t say for your site, but i’ve worked on speeding up wordpress site’s before, and let me tell you, it’s not an easy task. Wordpresses template and plugin nature makes it prime for backend bloat. After optimizing our wordpress blog we get an average time to first byte of 900 ms (still not optimum by far). You can achieve lower times by doing the following:
1.) Install something like w3 total cache. Though i’d say do your testing with this enabled and disabled. I found that it actually slowed down the total load time for me since i had already done manual optimizations.
2.) Go through your template and look for anything being called dynamically that you can add in statically. This will reduce the general amount of queries needed for the template generation.
3.) Do a slow query log and see if there are any opportunities to optimize the database itself via indexes. If anything it will tell you if you have some badly written plugins running.
4.) Keep plugins to a minimum.
Keep in mind that some of this slowdown may be masked by database query and table caching. So the actual backend delay may not appear as bad for your most accessed pages.
Another thing to watch out for is to make sure that your web server and PHP are both configured and tuned appropriately.
If the server runs out of available clients (really easy to do on apache with keep-alives) then it has to wait for a connection to close before it can service the next request.
For PHP, make sure you have APC installed/configured and that you’re running a reasonably fast configuration (FastCGI or something else that keeps the processes around and doesn’t keep spawning new ones).
If you don’t mind manually tweaking the rewrite rules, Nginx + PHP-FPM + APC is a SCREAMING fast combination that scales really well. It just doesn’t support .htaccess so it takes a little more work to get WordPress configured the way you want it. I moved WebPagetest from Apache + mod_php + APC to the Nginx/php-fpm combination and it was like night and day for handling a large number of requests.
Also, if nothing else jumps out as obvious, I’d recommend trying out the free trial of New Relic ( http://newrelic.com ). Don’t want to sound like too much of a product pitch but within a few minutes of installing it you should see the hotspots really quickly (and the 14 day trial is more than long enough to fix a bunch of stuff).
I used it on WebPagetest when I was doing the scaling work (to support the testing needs for the launch of Google’s Page Speed Service where traffic spiked from 40k page views/day to over 1M). There were a few seriously painful hotspots that I was aware of but didn’t realize quite how painful they were until I actually instrumented it.
Actually, while we’re on the subject, how easy is it to install new relic? Been considering it myself recently. If you have some personal experience with it i’d love to hear about it.
Instructions for PHP are here: https://support.newrelic.com/help/kb/php/new-relic-for-php
It was really easy to get up and running. I’m using Ubuntu 10.04 LTS so I went with the apt install:
The last step just runs a configuration script where you enter your account information.
It took me maybe 5-10 minutes to get up and running (and most of that time was reading docs just to make sure I was doing it right).
That does sound pretty easy to install. I will definitely be checking them out. Looking forward to grabbing sql query performance stats based on a true production environment.
After monitoring the results over the past few weeks since these great responses (thank you!!!) I have found wildly varying results. Sometime the TTFB will be 900ms, a very long time. Two minutes later it will be 250ms. There are also other tools that supposedly tell you TTFB and they are lower than they are here at times. Even with W3 Cache plugin and memcache installed I’m seeing some terrible TTFB numbers on occasion, which makes up 25% or more of my page load time. Strange - we’ll see. Thanks for the input and hopefully we can get to the bottom of this. I’ll consider newrelic – nice link, thank you.
Yes, that large of a variance is probably due to multiple levels of caching at work. Standard database caching will cache the result set of recently run queries, causing even a slow query to return results in as little as 0.06 seconds, but then later after the cache is invalidated the same query may take 2 seconds. I’d seriously recommend doing a slow query log or running something like New Relic, to see what queries are causing you issues. The performance you’re describing is textbook database overhead.
You don’t have to rely on one testing method. There are numerous websites offering free tests. Probably none is as pretty, and offers tests performed from various geographical locations, as webpagetest.org, but if unsure do your comparisons. Here’s one of many: Byte Check - Check Your Time To First Byte.
Browsers look for favicon.
You can also add server response times to your access log and pull stats directly from your server to see what the distribution looks like. It’s not unusual to see wildly varying results in first byte times from different pages/applications because it is usually a function of the database queries they run (number of and the specific queries).
Here is an example for WP Engine’s home page which is a wordpress site: http://www.webpagetest.org/result/111126_K2_2AA2Y/
They specialize in fast Wordpress hosting (using SSD’s for the databases) so it’s not surprising to see their first byte times so low but those numbers are achievable (just usually not on shared hosting where database performance is usually awful).