WordPress, Nginx and WP Super Cache

If you host your own WordPress blog, it’s probably on Apache. That all fine and good. For most sites Apache works wonderfully, especially as it’s so easy to find information on it, on mod_rewrite and everything else that everyone else uses.

One of the alternatives is Nginx, a really fast webserver that streaks ahead of Apache in terms of performance, but isn’t quite as easy to use. That’s partly because Apache is the default webserver on most Linux distributions and hosts. Want to try Nginx? Here’s how.

Install Nginx. On Debian based systems that’s as easy as

aptitude install nginx

Nginx doesn’t talk PHP out of the box but one way to do it is via spawn-fcgi. Here’s where it gets complicated. (Docs summarised from here)

Install php5-cgi. Again, on Debian systems, that’s

aptitude install php5-cgi

Edit /etc/nginx/sites-available/default and add the following chunk of code to the “server” section:

That’s the PHP part of things. In Debian, the default root is “/var/www/nginx-default” so put an index.php in there to test things out. Stop Apache and start Nginx (if this is a test server only!) and visit your site. Works? Now to get WordPress and WP Super Cache working.

Open up /etc/nginx/sites-enabled/default in your editor and comment out the text already there with # characters. Paste the following in. Change paths and domains to suit your site. (via)

I think the gzip settings above will compress cached files if necessary but Nginx can use the already gzipped Supercache files. The version of Debian I use doesn’t have gzip support compiled in, but if your system does, take a look at the gzip_static directive. Thanks sivel.

Finally, edit /etc/nginx/nginx.conf and make sure the user in the following line matches the user above:

user www-data;

I changed it to “nobody nogroup”.

Now, stop Apache and start Nginx:

/etc/init.d/apache stop; /etc/init.d/nginx start

WP Super Cache will complain about mod_rewrite missing, and you should disable mobile support.

How has it worked out? I only switched on Friday. The server did do more traffic than normal, but I put that down to the floods in Cork. Weekend traffic was perfectly normal.

Load on the site is slightly higher, probably because my anti-bot mod_rewrite rules aren’t working now. Pingdom stats for the site haven’t changed drastically and I think the Minify plugin stopped working, must debug that this week. Switching web servers is a huge task. I disabled mobile support in Supercache because I need to translate those rules to Nginx ones. A little birdie told me that he’s going to be writing a blog post on this very subject soon. Here’s hoping he’ll put fingers to keys soon.

Hi, I found (thanks Donncha, for the tip) that usingrewrite ^(.+)$ /index.php?q=$1 last;
will cause all pages (except the home pages) to remain un-supercached when running WP Super Cache in the default PHP mode. This is due to the ?q=$1 forcing all permalinks to become $_GET requests in the background, which will make WP Super Cache to back down.

I’m a big fan of nGinx and I’m using it already, but I wouldn’t recommend using it with php-fpm[1] instead of php-cgi. Also there’s a much simpler way of spawning a php-cgi socket by writing your own init-rc script[2] (requires no lighttpd).

I’ve switched to nginx recently too and it’s sweet!
I see major difference in memory usage and my server is much more relaxed now.

In the past you did various tests with ab, could you please tell us how it works with your nginx setup?

I run ab -c 100 -n 1000 on my server and
without SuperCache I get 22 requests/sec
with Supercache I get from 530 to 620 requests/sec
and on static files (gif,txt etc) inside my WP blog I get from 3100 to 3600 requests/sec

I found php processing time has not changed much. So, now I’m using it as a proxy before apache, serving files and static pages generated by Super Cache.

This way rewrites will work perfectly as before, and the load is lighter as well.

The kind of switch back is because I’m willing to manage my client’s domains with an opensource CP (maybe SysCP, maybe ispCP omega), and I can’t tell them, to write nginx rewrite rules, etc. This way I am going to have the best of both worlds 😉

Good stuff, Doncha. I actually set this up on a Slice over at Slicehost almost a year ago and have been loving it. The only different configuration I managed to work out was breaking out the code for Super Cache so I had the choice whether to implement it on a site install or not. Plus, I have different conf files for each domain install on the server (most of which are WPMU installs, BTW, 😉 )

So, in one of those site installs, I’ll create a new “location” section and insert the following:
# Basic version of WordPress parameters, supporting nice permalinks.
# include /usr/local/nginx/conf/wordpress_params.regular;
# Advanced version of WordPress parameters supporting nice permalinks and WP Super Cache plugin
include /usr/local/nginx/conf/wordpress_params.super_cache;
}

I have a bunch of virtual hosts on nginx, so I split out the WP/Super Cache rewrite rules into a separate file, and just include them from within whatever vhosts use WP. This makes things a lot cleaner.

Haha, man I can’t believe you just wrote this. I went through this whole process (with much googling) about a week ago. Talk about coincidences. This definitely has been a good move though, speed has increased incredibly from traditional setups of Apache and I’m much impressed.

My move was prompted by work on a new Federated Micropublishing tool which for testing purposes is easier on Nginx+Fastcgi then it is with Apache.

I’ll definitely keep this post bookmarked in case I have to do the process again in the future :P!

I’m running nginx in front of Apache for the time being. nginx directly serves static files, but passes PHP on to Apache. I’ll likely start experimenting with nginx/PHP solutions soon. I also want to use the Memcached module to have nginx serve pages directly from there, for multi-server setups. Batcache, but faster, because it’s not loading up PHP at all.

Though most of that was way over my head… I would be happy to learn more about your “anti-bot mod_rewrite rules” – is that to prevent automated “scanning” of the website (which I see happening alot in my stats)? does that create a problem for legitimate search engines?

After more than a year using Nginx+PHP in FastCGI mode and WP-Cache, the only thing I can say it’s that this is THE SOLUTION in order que get more of your servers. It’s solves 95% of the situations or problems on a website powered by PHP and MySQL.

Some months ago, I tried the WP-SuperCache plugin, but it didn’t work and it doesn’t work nowadays actually. The problem is that the plugin doesn’t write to the disk. I have checked all the things I can: users on execution, rights on the folders, path’s and so on.

As in my installation of WordPress (on a Russian hosting server dobrohost.ru, where nginx is enabled by default), there appear some problems with wp-cron and nginx. In versions prior to 2.7, the tasks were spawned with this code:

The socket was closed immediately, and nginx, working as a frontend for Apache, considered this as an error (#499 – the socket was closed prior to reply of webserver), the GET request was not relayed further and the task planner did not work. The problem can be resolved by adding a usleep(100000); delay (or a bit bigger, depending on the load of the server).

In further versions, wp-cron was rewrited and the tasks were spawned by this code:

The Nginx experiment is over. It didn’t reduce the load on my server, it did quite the opposite in fact which might have been a result of using php5-cgi. The load went up after I changed to Nginx, and when I installed P2 it made things worse because of the p2ajax requests looking for updates. Supercache can’t cache those requests so PHP was being executed for each of those requests, and there were a lot of them. People leave their browsers open all day!

Figures! I came up with my own solution just this week and you’ve already done it 🙂

Anyway, what I had come up with isn’t too far from what you’ve already done, except that I use Apache for the back-end and I have added support for mobile phones.

The mobile phone support was important to me, since I am using a different themes for those, which aren’t cached. I would post it here if it wasn’t such a long line (I’m checking for more mobile browsers than WP Super Cache does), so have a look at:

Just take that code that checks the user-agent, place it among the other “if .. set $supercache_uri” lines as shown here, and instead of ‘set $mobile “M”;’ you use “set $supercache_uri ”;”. Don’t forget to disable it in WP Super Cache itself 🙂

I use nginx + apache (mod_php). I did some testing, comparing apache vs FastCGI, where both only handle PHP scripts. The processing speed and rate at which the data was returned was almost identical. FastCGI was just a sliver faster, but I accounted that to some .htaccess rules I still had in place that Apache had to deal with.

Nginx on the front end is AMAZING when it comes to handing static content. Then let Apache or FastCGI do the heavy lifting of PHP and your website can handle much higher loads than normal.

I recently switched, almost everything works except for WordPress’s automatic upgrade core which sadly does not automatically do anything as of now.
Otherwise ram load drastically cut back and makes the switch worth it.

I wanted to ask about the http headers on nginx. I dont have much knowledge about it but it seems that nginx is not passing the http headers that super-cache sends by default (like etag and cache control).

Anyway, I manage to get WP + Supercache and Mobile support 100% operational on Nginx + FastCGI .. the only part that’s still cracking my head are the http headers, atm Im forcing some headers via nginx conf, but is not dynamic as it is over apache.

I really believe that nginx is way more efficient than apache in so many ways that is shocking. I manage to get almost a 70% improvement on speed v/s resource utilization with this setup … like 4 times better than nginx + apache2.. and probably my machine (a 16 core, 13 gb ram monster) will not be able handle my websites with just and apache2 installation.

Well, I offer my help if you are willing to try further on an nginx enviroment, is becoming very popular this days … even wordpress.org is using it on the server mix!

[…] not work with the nginx server, but nginx provides a powerful rewriting module too. A very helpful blog post from the WP Super Cache author helped to configure the web server. And now – at least for any […]

[…] covering an nginx Super Cache config today but if you’re interested Donncha himself provided one some time ago and a more recent one from Tim Purewhite which actually looks great – thanks for sharing […]

The Golden Compass
First of a three part fantasy/sci-fi series. Some people hate it because of it's anti God message but it's a great read. I found it hard to put down. There's even a Snopes article about the film adaptation.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.