Current time: 09-20-2019, 08:16 PM Hello There, Guest! (LoginRegister)

Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Another poor first byte time
07-28-2011, 04:02 PM
Post: #1
Another poor first byte time
Not sure what it is but here is a connection to a vbulletin forum - big fat F:

http://tiny.cc/cezic

And here is a front page, Wordpress gets a B:

http://tiny.cc/sm7u6

But this wordpress blog gets an F, same install, different front page:

http://tiny.cc/huu1c

Not sure how to explain the difference and what to do.
Find all posts by this user
Quote this message in a reply
10-24-2011, 03:34 PM
Post: #2
RE: Another poor first byte time
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?
Find all posts by this user
Quote this message in a reply
10-24-2011, 11:37 PM (This post was last modified: 10-25-2011 12:43 AM by jarrod1937.)
Post: #3
RE: Another poor first byte time
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.
Find all posts by this user
Quote this message in a reply
10-25-2011, 12:26 AM
Post: #4
RE: Another poor first byte time
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.
Visit this user's website Find all posts by this user
Quote this message in a reply
10-25-2011, 12:31 AM
Post: #5
RE: Another poor first byte time
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.
Visit this user's website Find all posts by this user
Quote this message in a reply
10-25-2011, 12:42 AM
Post: #6
RE: Another poor first byte time
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.
Find all posts by this user
Quote this message in a reply
10-25-2011, 12:59 AM
Post: #7
RE: Another poor first byte time
Instructions for PHP are here: https://support.newrelic.com/help/kb/php...ic-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:
- Add new relic to the apt sources
- apt-get update
- apt-get install newrelic-php5
- newrelic-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).
Visit this user's website Find all posts by this user
Quote this message in a reply
10-25-2011, 01:42 AM
Post: #8
RE: Another poor first byte time
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.
Find all posts by this user
Quote this message in a reply
11-21-2011, 05:48 PM
Post: #9
RE: Another poor first byte time
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.
Find all posts by this user
Quote this message in a reply
11-21-2011, 11:39 PM
Post: #10
RE: Another poor first byte time
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.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)