Experiments with Nginx

Lighter, smaller, faster, better? Nginx in action

There's no doubt that the Web runs on Apache. According to NetCraft, 47.1 percent of all Web sites are running on the crown jewel of the open source movement. Microsoft's IIS is a distant second at 24.8 percent, down a whopping 3.6 percent from last month. At third is qq.com, thanks to China, Google's fourth, and Nginx is fifth, running 3.7 percent of all Web sites. Nginx hasn't even been around for more than a few years, and it has only recently garnered any real interest. You'll be hearing much more about it, however. Nginx (or Engine-X) is a very impressive piece of code, currently running large sites like wordpress.com.

The whole impetus of Nginx is to be lighter, faster, and less resource intensive than Apache. To do this, it necessarily jettisons lots of functionality in favor of raw speed. For instance, Nginx can't handle CGI requests itself, so it proxies to another handler, like spawn-fcgi. But that's the idea -- you only need to run exactly what you need to run, without spending time and effort to pare Apache down to the bare essentials. In accordance to that design, a default Nginx installation has a very minimalist configuration that works fantastically for static Web tasks such as static HTML, style sheets, images, and so forth. For large sites that have dedicated image servers, it's not outside the realm of possibility that you could double the RPS from that server simply by moving to Nginx from Apache.

[ Stay up to date on the latest open source developments with InfoWorld's Technology: Open Source newsletter. ]

But what if you do need to push Nginx past simple static serving, into more advanced areas like URL rewriting, CGI tasks, and so forth? It can be done, though sometimes it gets, well, interesting. To start, let's look at a baseline Nginx configuration for a fairly beefy box:

user  www www;

worker_processes 2;
pid /var/run/nginx.pid;
# [ debug | info | notice | warn | error | crit ]
error_log  /var/log/nginx.error_log  info;

events {
    worker_connections   2000;
    # use [ kqueue | rtsig | epoll | /dev/poll | select | poll ] ;
    use kqueue;
}

This sets the user to run Nginx as, the error logs, the number of Nginx processes, and worker connections (note that I'm using kqueue here since this is a FreeBSD box). Pretty simple. Now, let's tweak some other settings: