Recent years have enjoyed a florescence of interesting implementations of Web servers, including lighttpd, litespeed, and mongrel, among others. These Web servers boast different combinations of performance, ease of administration, portability, security, and related values. The following engineering study surveys the field of lightweight Web servers to help you find one likely to meet the technical requirements of your next project.

"Lightweight" Web servers like lighttpd, litespeed, and mongrel can offer dramatic benefits for your projects. This article surveys the possibilities and shows how they apply to you.

What does it take to be a Web server?

The first important aspect is to understand clearly the domain under investigation (see Resources for details). The fundamental end-user action on the Internet is "going to a Web page." At a high level, this involves teamwork between a couple of applications:

• a Web browser, like Firefox or Internet Explorer, which requests a specific page and displays in human-readable form what it receives from...
• a Web server, generally on a remote machine, which responds to the page request with an HTML-coded or similar stream of data.

All Web users have direct contact with browsers, and there's a corresponding level of zealotry in their selection and analysis. Servers, though, are visible only to the sites' technical staff. Moreover, while there are scores of different Web servers in use, two account for around 90% of all sites, according to recent surveys by Netcraft: Apache and Internet Information Server (IIS). Both of these are highly refined products, boasting not only lengthy intrinsic technologic feature lists, but also thriving "aftermarkets" of books, add-ons, consultancies, providers, and so on. Is there any need to re-invent this particular wheel?

Yes. Important dimensions for evaluation of a Web server include:

• Performance: How fast does it respond to requests?
• Scalability: Does the server continue to behave reliably when many users simultaneously access it?
• Security: Does the server do only the operations it should? What support does it offer for authenticating users and encrypting its traffic? Does its use make nearby applications or hosts more vulnerable?
• Availability: What are the failure modes and incidences of the server?
• Compliance to standards: Does the server respect the pertinent RFCs?
• Flexibility: Can the server be tuned to accommodate heavy request loads, or computationally demanding dynamic pages, or expensive authentication, or ...?
• Platform requirements: On what range of platforms is the server available? Does it have specific hardware needs?
• Manageability: Is the server easy to set up and maintain? Is it compatible with organizational standards for logging, auditing, costing, and so on?

Apache and IIS can't optimize so many criteria simultaneously. Abstractly, it's obvious that niche products can surpass the market leaders in at least one or two of these dimensions.

The interesting thing about lightweight Web servers, and what makes them worthy of a survey such as this one, is that their competitiveness is more than just theoretical: Careful examination shows they have a lot to offer and hold their own against Apache and IIS even in many common situations. While it's reasonable to assume the market leaders have been carefully optimized to be effectively unbeatable in performance (for example), many tiny competitors are faster for simple service of static Web pages. When you run your own tests with these Web servers, you'll have the feeling that you showed up at a race track with a go-kart and are somehow passing the Porsches and Vipers. That's not all: There are times when lightweight Web servers complement, and not just compete, with their big brothers. Even if you know you'll be using Apache, you sometimes will get the most from it by teaming it up with a lightweight partner. The best solutions frequently involve co-operation between two or more Web servers.

The lightness of Web service

The "lightness" on which this survey focuses is rather a subjective quality, like "art" or "flavor." It generally means simple, easy-to-install, streamlined, undemanding, and robust -- smaller and less complex than Apache and IIS, certainly, which have grown rather baroque in trying to satisfy their mass markets. For this purpose, the complexity and size of the Java Web Server. AOLserver, and Zeus exclude them, despite their intriguing portability and performance.

Sufficiently lightweight servers open possibilities closed to the market leaders and other "heavy" alternatives. An entire server can fit in one file, for instance. This means it's convenient for a developer to carry around all the tools he or she needs to be productive; even if you run Apache on your production servers, you can sit in a hotel room and experiment with new ideas running on a lightweight server that takes only seconds to install. Also, because they're so undemanding, lightweight servers operate happily on hosts that simply can't stand up under the burden of IIS.

Single-file packaging

Small, lightweight Web servers also operate quite nicely on low-power hosts. In our own business (Phaseit -- see sidebar), we run dedicated hardware on industrial computers in remote, harsh, or underpowered environments. In those situations, it's a great advantage to be able to serve up Web pages through an application that requires little processing power or disk space; it means that our machines can build in Web-based management consoles, without the development and power overhead of Apache.

Nearly all the lightweight Web servers are open source, at some level. If we need special behavior from a Web server, the ones profiled below are so small that they're easy to understand, and therefore to enhance, with only a couple of exceptions. These Web servers make excellent raw material for projects that embed Web service, whether in special hardware, or in specific applications designed to run on general-purpose computers. They're also in widespread use among conventional-looking Web sites:

• YouTube depends on lighttpd for fast delivery of archived content such as videos;
• cdServe runs the "German Woodworking Machinery and Tools" CDs;
• LiteSpeed boasts of its role in the twitter, www.funnyoride.com, www.airliners.com, WordPress.com, fanfiction.com, SlashGear, www.forumactif.com, and other prominent Web sites;
• OpenSUSE, RubyOnRails, MarkaBoo, and several other prominent sites rely on Mongrel;
• thttpd is instrumental for demon.net, bluelight.com, mtv.com, The Drudge Report, garfield.com, and more;
• and so on.

Here's an example of the handiness of lightweight servers to developers: At our company, we work with special-purpose hardware that provides an office telephony solution. It's based on customized software that runs as a conventional Linux® application. With just one additional file and a bit of init.d configuration, it's easy to add a highly capable "Web console" that provides a management interface to the hardware and software. End users gain the ability to monitor and configure their boxes from any browser, without having to arrange special hardware connections or any of the other complications that were once common with "vertical" hardware.

Service-oriented architectures (SOA) have the reputation of being difficult and touchy. At least part of that challenge, in our experience, centers on correct Web service. We've taken advantage of lightweight Web servers to set up quick SOAs for demonstrations.

Lightweight servers even have a role to play in production datacenters, including the high-profile sites listed above, and more. Very high-performance sites segment their operations to make the most of caching, proxying, and so on. An Apache-based site, for example, might have an architecture which delivers slowly changing images through a minimal Web server from a dedicated filesystem. The results an end-user sees are actually the outcome of teamwork between Apache and one or more secondary Web servers, each playing a role at which it excels. Such an arrangement can deliver very fast results at minimum computational cost.

discuss this topic to forum