Skip to content
Archive of entries posted on June 2009

A smooth transition to nginx

After researching and testing nginx, a popular lightweight web server, I’ve ditched Apache, though not out of necessity. Yes, Apache is a memory hog, especially when processing dynamic requests, or serving a high number of clients. However, the sites on this server are insignificant enough to permit a low number of (mostly idle) Apache processes, so I never experienced memory exhaustion. My switch was purely spurred by boredom, I wanted something new to tinker with. A super-efficient web server with a minuscule memory footprint was simply a beneficial result.

At the time of writing, nginx (one master, four worker processes) is using 7.4 megs of memory. Now that’s low. Apache regularly consumed ~50 megs idle and quickly exceeded 80 under load. Even though nginx consumes very little memory, there’s still the matter of processing dynamic content. The php-cgi processes average ~20 megs total, somewhat high due to APC. So this brings my Apache-replacement memory total to ~27 megs.
If hit with a burst of traffic, Apache would spawn a large number of children, each with the ability to process dynamic content, etc. regardless if they were doing so… a recipe for wasted memory. With php-cgi, the number of processes can be set to a fixed level. When combined with caching (e.g. the WordPress wp-super-cache plugin), nginx does nearly all of the work, and the php-cgi processes sit mostly idle, ready to serve cached bytecode courtesy of APC.

Although the original documentation for nginx is Russian, there’s a valuable, up-to-date, multi-language wiki. For community assistance, one can turn to #nginx on Freenode and the forum/mailing list, in which the latter nginx’s creator, Igor Sysoev, is active.

As there are oodles of guides on nginx, I won’t bore you with my transition process, nor share my configuration. Also, since I’m new to nginx and still learning, I would hate to share what could be a borked config. That said, go find some example configurations, head to the wiki to figure out precisely what the directives do, and then tweak to your heart’s content!

What I will do is caution against the use of the spawn-fcgi wrapper when using a FastCGI backend to process PHP. Many guides advocate its use without explaining why. The PHP CGI interpreter alone will suffice… I can find no reason to use a wrapper between PHP and nginx, and I believe it serves only as another potential point of failure.
Oh, and if you plan to run nginx on Debian or Ubuntu, you can run
apt-get source nginx
and find a working init script at nginx-0.x.x/debian/init.d

For those of you intending to run WordPress on nginx and are interested in SEO, I suggest you take a look at the nginx-compatibility plugin.