Linode Forum

[picajoso]

Hi,

I've got a Linode 2048 VPS for one of my big blogs, and I'm experimenting issues with the load time. Running a simple test with Pingdom Tools gives me a wait time of around 11 seconds just to start getting data from the server.

As far as I know this is called "Time to first byte", and I can't understand why this is happening. My server is based in Nginx, PHP-FPM (5.3.3) and the latest WordPress 3.3 version.

The Pingdom report shows that first access to my blog, www.muycomputer.com, and there's a big yellow zone that lasts 11 seconds and that means that "The web browser is waiting for data from the server".

Here you can find a screenshot to provide more information.

http://i.imgur.com/a7Qrx.jpg

Could somebody help me with this?
Could it be an issue with the Linode configuration (not my webserver, I mean Linode dashboard)?

[KyleXY]

Running the test myself achieved different results.
http://i.imgur.com/sf8SF.png

[picajoso]

Interesting. If someone else can run the test from their location, that could confirm one or the other result.

Anyway, if it is just a question of location... should I move my server out from Linode (London, which is pretty near to Madrid, where we work)?

[zunzun]

picajoso wrote: Could it be an issue with the Linode configuration (not my webserver, I mean Linode dashboard)?

This static image file:

http://www.muycomputer.com/wp-content/themes/muycomputer/images/cabeceraMC.jpg

comes back immediately. There seems to be a difference between your site serving static image files and other content, that should be a clue in finding the problem.

James

[hoopycat]

Looks fine here: http://drop.hoopycat.com/muycomputer-timing.png

I requested the page at 13:18:25 GMT and the bottom of the page has:

<!-- hyper cache: e102eaba63416ac5d60e5c434edf400f 12-01-03 01:16:18 -->

I don't think it's Linode-related. It's probably either related to something on the PHP or the database side of things. Or, it could have been Pingdom's tool having a bad day.

[picajoso]

Thanks for the suggestions. Yesterday I cleaned, repaired and optimized database (also deleted and disabled post revisions and pingbacks), but there's been no effect at all.

I'm checking the logs, and there are lots of "closed keepalive connection", but as far as I know this is pretty normal and I can disable those warnings adding a "notice" at the end of the error_log directive.

Hoopycat, when you mention the hyper cache line, do you think that has something to do with the issue?

I've ran again the test, and the problem remains... (Spanish IP, again).

http://i.imgur.com/lZbbH.jpg

[hoopycat]

tools.pingdom.com runs its tests from their servers, not from your location; the last one you posted was performed from Dallas, Texas. Click the "Settings" slidedown to tie it to a specific location. Should only make a few hundred milliseconds' difference, though.

I was mentioning the hypercache thing because caching usually results in better performance. It would be worth keeping an eye on that as you try various things.

What are you using for a database server? If it's MySQL, try running mysqltuner.pl, and make sure your slow query log is enabled. That will hopefully find any issues there. Also, if you're using the default configuration in MySQL before 5.5, you're probably using MyISAM instead of InnoDB; if you have some things that are writing to the database on each hit, MyISAM will slow things down drastically. (I believe this will show up in the slow query log.)

Also, if you want a quick and easy way to isolate just this problem without any other effects or having to fire up a web browser,

Code: $ curl --output /dev/null http://www.muycomputer.com/
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  104k    0  104k    0     0   9697      0 --:--:--  0:00:11 --:--:-- 27876


You can run that from your Linode itself. You can also write the output to /tmp/something instead of /dev/null if you want to save the HTML for comparison. I actually wish I'd done that in the example I pasted above, because now when I do it, it completes in under a second!

[hybinet]

Canada here. Your site loads instantly. According to the hyper cache footer, the page I saw was generated 30 minutes ago.

You're using a caching plugin, which means that most visitors (like me) will see a cached version of your home page, which loads instantly. But some visitors will arrive on a cold cache, and WordPress will have to generate a new page from scratch. This can be much slower, especially if you use a badly written third-party plugin. Some WordPress plugins are really helpful, but some are just plain horrible. They could be sending really bad queries to your database, or they could be waiting too long for a remote API such as Twitter.

It's difficult to diagnose a WordPress performance issue while a caching plugin is enabled. Disable hyper cache for a while, and then use the slow query log (as hoopycat said) to see if there are any rogue queries. Re-enable hyper cache when you're done.