Time to first byte...

You know, I have been having the same problem myself but with a completely different setup and software. Time to first byte is around 5 seconds with Litespeed and vBulletin.

I assume this is a follow-up to this thread?

Interestingly, time to first byte is 4 seconds only on the front page, and subsequent pages all load in around 1 second. When I return to the front page, it's 4 seconds again. This is strange because all pages seem to be using Total Cache. Is there anything special on the front page that might make it slow or un-cacheable?

The headers seem to indicate the main page isn't cacheable:

< HTTP/1.1 200 OK
< Server: nginx/1.0.11
< Date: Tue, 17 Jan 2012 02:22:32 GMT
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< X-Pingback: http://bladereviews.com/xmlrpc.php
< Link: <http: wp.me="" 1ezi2="">; rel=shortlink
< Last-Modified: Tue, 17 Jan 2012 02:22:32 GMT
< Vary: Cookie
< X-Powered-By: W3 Total Cache/0.9.2.4</http:> 

(a little while later)

< HTTP/1.1 200 OK
< Server: nginx/1.0.11
< Date: Tue, 17 Jan 2012 02:24:06 GMT
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< X-Pingback: http://bladereviews.com/xmlrpc.php
< Link: <http: wp.me="" 1ezi2="">; rel=shortlink
< Last-Modified: Tue, 17 Jan 2012 02:24:06 GMT
< Vary: Cookie
< X-Powered-By: W3 Total Cache/0.9.2.4</http:> 

The Last-Modified time there should be before now. Only difference between the two outputs is the timestamp from W3 Total Cache:

$ diff /tmp/bladereviews.1 /tmp/bladereviews.2 
629c629
< Served from: *.bladereviews.com @ 2012-01-16 19:22:32 -->
---
> Served from: *.bladereviews.com @ 2012-01-16 19:24:06 -->

@hybinet:

I assume this is a follow-up to this thread?

Interestingly, time to first byte is 4 seconds only on the front page, and subsequent pages all load in around 1 second. When I return to the front page, it's 4 seconds again. This is strange because all pages seem to be using Total Cache. Is there anything special on the front page that might make it slow or un-cacheable?
In a manner of speaking, yes; though, like I said, since then I've gone to nginx+php5-fpm. I credit some folks here for the help because I searched around before posting ;)

And yes, I noticed that, as well. I don't have access to the WP Dashboard, so I'm not certain what might set the index page apart.

@hoopycat:

The headers seem to indicate the main page isn't cacheable:

[...]

(a little while later)

[...]

The Last-Modified time there should be before now. Only difference between the two outputs is the timestamp from W3 Total Cache:

$ diff /tmp/bladereviews.1 /tmp/bladereviews.2 
629c629
< Served from: *.bladereviews.com @ 2012-01-16 19:22:32 -->
---
> Served from: *.bladereviews.com @ 2012-01-16 19:24:06 -->

Alright, I'll see about getting him to let me have a look at his cache config and report back. Thanks fellas.

W3 Total Cache has a mind-boggling array of different caching modes. I wouldn't be surprised if it served a cached page (or constructed it from a number of cached HTML snippets) and then added headers and a comment with individualized timestamps. This, of course, requires firing up the WordPress engine and loading the heavyweight caching plugin every time. Much less efficient than simply serving a static file.

Touched base with the client and told him to take a look at his config, he's seeing:

> It appears Page Cache URL rewriting is not working. If using apache, verify that the server configuration allows .htaccess or if using nginx verify all configuration files are included in the configuration.

and

> It appears Minify URL rewriting is not working. If using apache, verify that the server configuration allows .htaccess or if using nginx verify all configuration files are included in the configuration.

I used the W3TC rewrite rules for nginx found here during initial config:

http://codex.wordpress.org/Nginx#W3TotalCache_Rules

Maybe needs some tweaking?

@rawsted:

http://codex.wordpress.org/Nginx#W3TotalCache_Rules
Those rules look incomplete. There's not a single "rewrite" in there. It's not rewriting any URLs, only adding browser cache headers to static files.

Unfortunately, I can't seem to find anything better.

@hybinet:

Those rules look incomplete. There's not a single "rewrite" in there. It's not rewriting any URLs, only adding browser cache headers to static files.

Unfortunately, I can't seem to find anything better.
So there isn't…well, surely someone else is running nginx/WP/W3TC here…what are they using?

Also, how the hell is the site working with no explicit index.php/args rewrite?

@rawsted:

Also, how the hell is the site working with no explicit index.php/args rewrite?
Isn't that what the General WordPress Rules are for?

I just found this. It's a bit old, but it might help. Even if that's not exactly what you need, a proper rewrite rule for a caching plugin should look something like that.

@hybinet:

Isn't that what the General WordPress Rules are for?
Yes, I was just here myself looking back at these and realized I was missing the:

fastcgisplitpath_info ^(.+.php)(/.+)$;

Directive. However, it doesn't resolve the "…rewriting not working" messages in W3TC

@hybinet:

I just found this. It's a bit old, but it might help. Even if that's not exactly what you need, a proper rewrite rule for a caching plugin should look something like that.
Just tried this, doesn't seem to be doing the trick, either.

Edit:

Do'h…W3TC has rewrite rules for nginx listed in the installer…I'm going to make sure it's the latest version, update if necessary, implement those and report back.

Alright! Implementing those cleared the page cache/minify rewrite error notices…but the index page still loads relatively slowly. Current server response headers:

Cache-Control:no-cache, must-revalidate, max-age=0
Connection:keep-alive
Content-Encoding:gzip
Content-Type:text/html; charset=UTF-8
Date:Tue, 17 Jan 2012 19:52:59 GMT
Expires:Wed, 11 Jan 1984 05:00:00 GMT
Last-Modified:Tue, 17 Jan 2012 19:52:55 GMT
Link:<http: wp.me="" 1ezi2="">; rel=shortlink
Pragma:no-cache
Server:nginx/1.0.11
Transfer-Encoding:chunked
X-Pingback:http://bladereviews.com/xmlrpc.php
X-Powered-By:W3 Total Cache/0.9.2.4</http:>

Expires:Wed, 11 Jan 1984 05:00:00 GMT
Last-Modified:Tue, 17 Jan 2012 19:52:55 GMT

Culprits?

Interestingly, another page which loads rapidly shares the same response headers:

Cache-Control:no-cache, must-revalidate, max-age=0
Connection:keep-alive
Content-Encoding:gzip
Content-Type:text/html; charset=UTF-8
Date:Tue, 17 Jan 2012 20:01:40 GMT
Expires:Wed, 11 Jan 1984 05:00:00 GMT
Last-Modified:Tue, 17 Jan 2012 20:01:39 GMT
Link:<http: wp.me="" p1ezi2-s1="">; rel=shortlink
Pragma:no-cache
Server:nginx/1.0.11
Transfer-Encoding:chunked
X-Pingback:http://bladereviews.com/xmlrpc.php
X-Powered-By:W3 Total Cache/0.9.2.4</http:>

Strangely enough, the time to first byte metric is now down into an acceptable (you might even say fast) range. Perhaps the cache just needed some time to catch up after the configuration correction? Let's look at the headers again…

Connection:keep-alive
Content-Encoding:gzip
Date:Tue, 17 Jan 2012 20:30:27 GMT
Last-Modified:Tue, 17 Jan 2012 19:46:24 GMT
Server:nginx/1.0.11
Vary:Accept-Encoding, Cookie
X-Powered-By:W3 Total Cache/0.9.2.4

Looks better. Thanks fellas!

As an aside, what should I set the keepalive timeout in nginx for? Atm it's 30

@rawsted:

As an aside, what should I set the keepalive timeout in nginx for? Atm it's 30
30 is much longer than necessary, because most pages finish loading in just a few seconds. But usually it doesn't matter because idle connections consume very little resources in nginx. That's one of the most significant differences between Apache+PHP and nginx.

Off, or very low, like 1.

EDIT: Although as was pointed out, this matters less in nginx than apache

@hybinet:

30 is much longer than necessary, because most pages finish loading in just a few seconds. But usually it doesn't matter because idle connections consume very little resources in nginx. That's one of the most significant differences between Apache+PHP and nginx.
1 it is. Thanks again!

@hybinet:

30 is much longer than necessary, because most pages finish loading in just a few seconds. But usually it doesn't matter because idle connections consume very little resources in nginx. That's one of the most significant differences between Apache+PHP and nginx.
@Guspaz:

Off, or very low, like 1.

EDIT: Although as was pointed out, this matters less in nginx than apache
1 it is. Thanks again!

Edit:

Double post for the lose :(