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.
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 journalism.cuny.edu [txt].