Wandering Thoughts archives

When I'd use a web server other than Apache

As I mentioned last entry, while I've come around to Apache as my default choice for new web servers there are still situations where I would start with something else. Of course the obvious case is when you've assessed and measured your web site and you've determined that some other web server is the best choice (for whatever reason). Here, I'm interested in more general cases, ones where I haven't done any particular specific measurements and so on.

Right now, there are three general cases where I would reach for something other than Apache:

• if I had a machine with constrained resources. Apache is many things but it is generally not a lightweight web server. I'm sure you can make it one if you know exactly the right configuration options for your specific usage, but I'd rather start with something that was explicitly designed for that from the start.

• if I wanted the web server to have predictable and limited resource usage, with a very low chance of blowing up the machine even if it got hit with unexpected load. You can do this in Apache with the right configuration options but Apache is sufficiently complex that just what these options are is not particularly obvious (and you need not to miss something in the corner). A number of other web servers are much more predictable, especially ones that do all of their work in a single process.

  (This is generally true even for dynamic content, partly because the other web servers generally require you to run your dynamic code in a way that exposes obvious limits on it. For example, they may require you to run your dynamic code in a separate FastCGI-based server and then the server is highly likely to have a clear configuration setting for things like 'how many processes at once'.)

• if I had a sufficiently simple configuration, generally for static files and other simple things, and I didn't want to pay what I'll call the Apache configuration tax. Apache configuration files are complex and verbose, partly because Apache supports so much and partly because of history. Other web servers often have much simpler single-file configurations, at least in the simple case.

Of course these cases can combine.

(While we use Apache for our serious web servers, we actually have a few trivial ones here that run Lighttpd for a combination of the second and third reasons.)

Why Apache is such a temptation

We all know the hulking monster of Apache. Encrusted with decades of history and baroque trim, it's not exactly renowned for being speedy or lightweight and it's famously common for it to explode your machine under load if it's not configured exactly right; in trying to be everything for everyone it does nothing particularly well (so it's commonly said). The usual prejudice is that everyone sensible uses a modern, lightweight web server that's designed for today's operating systems and web environments, something like lighttpd or nginx or a number of others. Only ignorant people still run Apache.

(Remember, I said this was a prejudice.)

Well. I've run Apache and I've run lighttpd, and the process of doing both has given me some opinions on this. The summary is that unless I'm in an unusual situation, the next web server I set up for myself will use Apache.

Apache has two large temptations. The first one is that whatever you want to do, Apache probably has support for it; with other web servers, you take your chances. Apache has a dizzying array of features and modules that cover a huge range of ground. A lot of people don't like this (it's part of what makes Apache a hulking monster), but it's tempting in just the same way that the GNU tools are.

The other temptation is that as part of the 'everything but the kitchen sink' approach, Apache generally does almost everything it can for you. My poster child for this is support for HTTP compression. Any number of web servers have modules for compressing static resources, but Apache goes the extra distance to also compress the output of CGI programs (and other dynamic resources). What this means in practice for us is that all of our users' CGI programs take advantage of HTTP compression; without this I'm pretty confidant that most of them wouldn't.

(If you use a big framework to implement your dynamic website, it probably has direct support for compression. But if you aren't using someone else's code, you're probably not going to implement compression yourself; there are a bunch of issues and most people don't have the time and interest. I certainly don't, which is why WanderingThoughts has HTTP compression and another DWiki instance I run elsewhere under Lighttpd doesn't.)

As a corollary of this, Apache is also the tempting choice if you're a sysadmin and you don't know just what features people will wind up needing or wanting. Since it has everything but the kitchen sink, you can probably give people almost anything they wind up asking for.

There are still situations where I'd use something other than Apache, but what they are is a sufficiently complicated issue that it needs another entry.