Time to First Byte really long, why?

Running the test myself achieved different results.

http://i.imgur.com/sf8SF.png

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)?

@picajoso:

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/t … ceraMC.jpg">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

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:

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.

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

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,

$ 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!

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.