Apache Vs Nginx Vs Lighttpd: Comparing Performance, Resource Usage And Features

Recently I’ve encountered a special case scenario where Nginx strict configuration rules seemed to be unable to accommodate the specific directions I wanted them to carry. From that point, one thing led to another and all of a sudden I found myself researching open source web (http) servers in order to find the one that could provide me with high performance while being flexible at the same time.

Below you’ll find the fruits of my labor, after making lots of vigorous testings and tweaking in order to find the ultimate server which I set out to find.

Oh, and for the curious among you, here’s the Nginx “riddle” I was facing. See if you can solve the following configuration task before you finish reading the article. I’ll reveal the answer at the end of the article:

[Nginx Configuration Riddle]

Nginx rules structure ordered by priority:

1. = (exactly) : location = /path
2. ^~ (forward match) : location ^~ /path
3. ~ (regular expression case sensitive) : location ~ /path/
4. ~* (regular expression case insensitive) : location ~* .(jpg|png|bmp)
5. / : location /path

Your mission is to be able to direct all http requests to https as long as they do not contain the phrase “no_redirection” in them. Requests that do contain “no_redirection” are to return a 410 error page.

So urls such as:

http://iwf1.com
http://iwf1.com/no_apache-vs-nginx-vs-lighttpd_redirection
http://iwf1.com/apache-vs-nginx-vs-lighttpd?redirection_no

are valid for redirection, whereas urls such as:

http://iwf1.com/no_redirection
http://iwf1.com/no_redirection/http_servers_comparison
http://iwf1.com/no_redirection?apache-vs-nginx-vs-lighttpd

are invalid, and should return error 410.

My starting point was these rules:

if ($scheme = http) {
return 301 https://$server_name$request_uri;
}

and

location ~ /no_redirection {
return 410;
}

Needles to say the rules above couldn’t deliver the required behavior.

And now, on to the comparison.

The Servers

Apache

Apache made its first appearance on 1995, continuing another http server project (the public domain HTTP daemon) which development started to stall after the main developer had left the project. A group of aspiring webmasters then got together in order to coordinate their patches and bugfixes to the server and thus Apache was forged (a Patchy server).

With over twenty years of experience, Apache gained popularity^[1] and accumulated lots of features along the way, possibly to the point where it may have become bloated, some would say.

Claim to fame: feature-packed, most popular web server.

Myths to shatter: resource-hog, slow.

Lighttpd

Lighttpd (pronounced “lighty”) was first introduced to the world on 2003. Originally it was a proof of concept that the C10k problem can be solved, i.e. that one server can be made to handle 10,000 connections in parallel. Thanks to that proof, the high performance server later became quite popular that at some point it was even adopted by large scale sites such as YouTube, Reddit, ThePirateBay and so on (all three seem to have moved on to other servers by now though).

Upon gaining popularity, the large userbase had inevitably started filling the role of testing Lighttpd – a role which the small developers team apparently couldn’t cover fully. Some bug reports were filled regarding allegedly found memory leaks, most prominently concerning the F/CGI implementation which gave rise to rumors about Lighttpd being unstable.

Claim to fame: fast, solves the C10k problem.

Myths to shatter: buggy, contains memory leaks.

Nginx

Nginx (pronounced Engine X) was first publicly released on 2004. Just like Lighttpd, Nginx was also set out to solve the C10k problem, but being published a year after Lighttpd, it wasn’t credited for it. Its main premise however, became a lot more dominant as time went by: using asynchronous event-driven approach to handle requests.

The same approach have made it one of the most high performance servers out there today, being the second most popular in the world, according to recent statistics^[1]. Yet Nginx strive for high performance comes with a price, the server has a set of rules which priority is unconfigurable, it also doesn’t allow for overriding systemwide access settings on a per-file basis (more on that below).

Claim to fame: asynchronous, event-driven.

Myths to shatter: limiting, strict.

Features

It is widely known that when it comes to features, Apache is one of the leading web servers out there to supply you with the feature you want. But how does it compare to Nginx and Lighttpd?

Before you, are lists of modular features each server can be compiled with. These features can be used either as plug-able modules which you can then set the server configuration to use, or, these features can also be compiled statically, meaning not as modules but rather built-into the server instead.

Note: the lists are scroll-able.

[ + + means installed, – – means not installed. ]

Apache-2.4.27-r1:

Total of 94 modular features

Nginx-1.12.1:

Total of 93 modular features

Lighttpd-1.4.45:

Total of 22 modular features

Quite surprisingly, when looking at the total sum of each list, it seem as though Nginx has managed to almost catch up with Apache’s feature set. Lighttpd on the other hand is still lagging behind, and perhaps it’s for the better because the name Lighttpd do suggests lightweight-ness.

Also, here are some things that aren’t being reflected by the lists above –

• First of all, let’s start by mentioning that most users won’t even need all these features in the first place. For instance, Apache’s “xml2enc” module or Nginx’ “uwsgi” http module would probably not be part of any standard installation. It’s good to have them there as options, but it probably won’t make any difference for many users if they weren’t.
• Another point I want to emphasize is that some of these features’ names do not reveal their actual nature, and what I mean by that is, for example, Apache’s http2 implementation also allows you to use the “h2c” directive which can upgrade http/1.1 connections to http/2 (note that web-browsers only supports http2 over ssl, i.e. https), whereas Nginx’ http2 implementation allows for setting http/2 connection only (meaning no connection upgrade, either the connection is v. 1.1 or 2.0).
• Thirdly, neither Nginx nor Lighttpd have any equivalent to Apache’s decentralized approach, where one could use “.htaccess” files to override systemwide directives. Apparently, the centralized approach is more geared towards performance as some of the tuning advice for Apache you’ll find in many online resources like to suggest – turning off htaccess support by using the directive: AllowOverride None in httpd.conf. That said, without htaccess (or equivalent) shared hosting would probably be a real flop.

Now personally, the features I cared about, besides the basics of course – rewrite, redirect, include, etc…, were: support for ssl, http/2 connections, php-fpm, and of course flexibility and speed (but we’ll get to that later on).

I found that both Apache and Nginx could accommodate my requirements but as for Lighttpd, I would have to compromise on http/2.

Configuration Syntax

Before ending up the Features section and moving on to the next topic, I’d like to draw your attention to each server’s configuration syntax as a feature in its own. While most readers may be familiar to some extent with Apache’s configuration syntax or Nginx’s, many are probably unfamiliar with Lighttpd’s one, and more importantly – how does the syntax actually serves as a feature of the server.

So starting with the most widely known one – Apache. Apache’s configuration syntax is quite broad and well structured it uses predetermined directives to enable the user an easy way to configure the server (instead of, for example, requiring the user to write code). It also allows the user to include wildcards within the scope of each directive, or use a dedicated regex directives instead. Apache does not prioritizes clear-text syntax over regex one. The priority of directives is then determined by order of placement or by closer match (regardless if the match is reached by regex or plain text), for example:

<Files "index.html">
Require all granted
</Files>

<Directory "/mydir">
Require all denied
</Directory>

The above configuration will deny anyone from accessing files inside “mydir” directory unless the file requested is “index.html”, and that’s depite the fact that “Require all denied” is set after “Require all granted”.

Similarly to Apache, Nginx also comes with directives and dedicated directives for regex built-in as part of its syntax, however, whereas Apache does not prioritizes clear-text over regex Nginx on the other hand does, since an exact match cannot equal a regex expression (see Nginx Configuration Riddle above for the rules priority order).

Lastly we have Lighttpd which have a rather small range of directives (compared to Apache for instance) and within those directives the user is mostly required to use either a predefined value, for example:

server.event-handler = "linux-sysepoll"

or, in some places where it fits, the user is encouraged to use regex, for instance:

url.redirect = (
"^/wishlist/(.+)" => "http://localhost/$1"
)

The prioritization is then made by order of placement.

Considering all three approaches, it seems Lighttpd is both the most minimal as well as the most open one as it doesn’t have regex directives separated from clear-text nor does it prioritizes any directive in particular. Priority is basically trusted in the user’s hands which can be controlled merely by order of placement. In that regard Apache could be considered as having the second most open approach as it does require dedicated regex directives and lastly, Nginx’s approach is a little more strict than the others, having the priorities predefined by the server.

Category Rankings

1 Apache

2 Nginx, Lighttpd