Proxy caching WordPress with Nginx

Nginx is a lightweight web server/load balancer/reverse proxy designed to drive blazingly fast websites. It has low resource requirements compared to Apache, the defacto standard for PHP-based applications, and can handle an order of magnitude more requests per second.

With WordPress, Nginx is often used in a few different ways: to serve static media assets, to execute PHP for WordPress, or to reverse cache Apache responses. You’ll want to install Nginx, put it in front of Apache, and then choose one option or go for all three. Mike Green has comprehensive documentation to cover the first and third scenarios. It’s more or less what I did at the J-School.

Epic foo is using Nginx as a reverse proxy cache. “Reverse proxy cache” means Nginx will generate a static cache of everything Apache responds with, and then serve this cache as long as you’d like. For us, this means homepage response time has dropped from an average of 1.5 seconds to around 25 milliseconds. On pages without a lot of secondary images and Javascript (e.g. not the homepage), load times are now wicked fast.

It’s worthwhile to note we’re only serving cache to non-authenticated users. Students and faculty expect our website to behave like an application, and to have changes they make appear immediately. This is less of an issue for other visitors. Caching also gives us protection against bursts of unexpected traffic.

Proxy caching was deceptively simple to implement. I spent around 15 work hours in September trying to get it to work, gave up until November, and then solved the problem in 15 minutes with a stroke of brilliance. Originally, I followed the configuration settings specified in Dan Collis-Puro’s awesome WordPress plugin and it took our setup to 80% completion. I then learned the most important thing is to tell Nginx to log cache hits; this makes it far easier to determine whether caching is working or not. The second most important thing is to turn proxy_redirect off. I still don’t fully understand what the declaration does, but it was the crucial missing piece. Seeing dozens of “HIT”s scroll by never felt so good.

Check out our commented master Nginx configuration file [txt] and the configuration file specific to [txt].


Dan Collis-Puro November 30, 2010 Reply

It’s like magic, isn’t it? I love nginx.

We get a ton of ‘bot traffic (bad and good) – check out the limits you can apply via limit_zone and limit_req_zone. Hawt. These directives have caught a ton of malicious spiders for us.

More discussion of this plugin / integration strategy here.

Leave a Reply