Linode Forum

rawsted · Joined: 07 Jan 2012 Posts: 23

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

Ghan_04 · Joined: 03 May 2011 Posts: 52

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.

hybinet · Joined: 02 May 2008 Posts: 1058

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?

hoopycat · Posted: Mon Jan 16, 2012 9:26 pm Post subject:

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

Code: < 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)

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

Code: $ 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 -->

rawsted · Joined: 07 Jan 2012 Posts: 23

hybinet wrote: 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 wrote: The headers seem to indicate the main page isn't cacheable:

Code: [...]

(a little while later)

Code: [...]

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

Code: $ 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.

hybinet · Joined: 02 May 2008 Posts: 1058

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.

rawsted · Joined: 07 Jan 2012 Posts: 23

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

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

Quote: 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#W3_Total_Cache_Rules

Maybe needs some tweaking?

hybinet · Joined: 02 May 2008 Posts: 1058

rawsted wrote: http://codex.wordpress.org/Nginx#W3_Total_Cache_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.

rawsted · Joined: 07 Jan 2012 Posts: 23

hybinet wrote: 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?

hybinet · Joined: 02 May 2008 Posts: 1058

rawsted wrote: 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.

rawsted · Joined: 07 Jan 2012 Posts: 23

hybinet wrote: 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:

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

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

hybinet wrote: 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.

rawsted · Joined: 07 Jan 2012 Posts: 23

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

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

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

rawsted · Joined: 07 Jan 2012 Posts: 23

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

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

rawsted · Joined: 07 Jan 2012 Posts: 23

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

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

hybinet · Joined: 02 May 2008 Posts: 1058

rawsted wrote: 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.

Time to first byte...