So with the help of some folks here and a little personal initiative, I made the switch to nginx/php5-fpm from apache2/mpm-prefork. Everything is running smoothly, except the time to first byte is in the 4.x range - an improvement, but still leaves something to be desired. This might be something I'll wind up needing to pass along to the client (who is the one with WP-admin and control over the site), but as of right now I haven't the foggiest as to the culprit(s). Suggestions?

Site is http://bladereviews.com

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

(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

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

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.


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:



and



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

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

Maybe needs some tweaking?

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?

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.

Yes, I was just here myself looking back at these and realized I was missing the:

fastcgi_split_path_info ^(.+\.php)(/.+)$;

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


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

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

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

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.