At the time of writing this article the web is effectively powered by three different major web server software packages. A web server, as covered in this article, basically has two purposes. One is to serve static (no dynamic functionality, no backend, no database, …) web sites, usually consisting of HTML, and CSS plus images etc. The other is to act as a to web application backends. The three servers I just mentioned have a combined market share of 94.7 % (according to ) and are named (or ) (written in C), (say ) (also written in C) and (written in C++). While the first two are platform independent and open-source, the latter is a proprietary, commercial, Windows-only product and therefore more interesting at enterprise level rather than for smaller indie projects. Consequently I won’t cover IIS further in the following. JavaScript reverse-proxy this statistic Apache 2 httpd nginx “engine ex” Microsoft IIS Microsoft Most popular web servers on the internet ( Source ) nginx’ first release was in 2004 and Apache2’s roots even date back to 1995. Of course both projects are getting updates regularly, but their base concepts still remain the same. And at some point they might not perfectly fit today’s requirements anymore. Personally I switched from Apache2 to nginx a few months ago mainly because of two reasons. The first one was that I had really been annoyed by Apache2’s . The second reason was that Apache2 still didn’t have HTTP/2.0 support in 2016. extremely high memory overhead Apache2 vs. nginx memory usage ( Source ) I was pretty happy with nginx and especially its performance as well as the large amount of documentation and forum posts on the web about every conceivable problem were great. But since I’m a developer and not a sysadmin there’s one thing I didn’t like. The configuration is not that intuitive and you really need to get into the syntax and concepts to get an understanding of which knobs to turn in order to achieve a certain goal. It’s also much more fine-grained than necessary for the average user. Personally I just want a simple config file with an intuitive syntax where I can tell my web server which static content to display or which backend to reverse-proxy for which route / domain. This, plus some additional features like handling compression, TLS encryption, authentication and maybe some basic rewrites, is fine. Looking for a more modern web server that fulfills these requirements I found . As it turned out, it can even do a lot more cool things, while still being easy to use. Caddy Caddy is written is Go, open-source and pretty actively (according to commit history) developed on . The goal when developing Caddy was exactly what I was looking for: easy configuration and fitness for today’s web applications. It comes with HTTP/2.0 (and even QUIC) support out of the box and serves via HTTPS by default (HTTP to HTTPS redirection is also handled automatically, while you manually had to tell Apache2 or nginx to do so). It even obtains (and regularly renews!) certificates for every (sub)domain you specified in the config file. While enabling HTTPS for a site was really a pain some years ago, it’s done completely automatically now. You don’t need to run any script. You don’t even need to create a Let’s Encrypt account or install the . At the center of Caddy is the (or ), which are added to the config as a one-liner. The is long and you will find a middleware for almost everything. For instance there are middleware components for logging, gzipping, header modification, (basic or -based) authentication and load balancing. But also more fancy things like automatically serving Markdown as HTML, a plug-and-play file browser GUI, HTML minification, IP filtering or pattern-based text replacement in HTML files are available as middlewares. Caddy also aligns well with PHP, using , just as nginx does. As usual with Go applications, the entire program is shipped as a single binary (available for Windows, Mac, Linux and BSD), which includes all of its dependencies. Consequently you don’t need to install any further libraries to be linked (-> no version conflicts), what really makes the installation a no-brainer. However, this introduces one little drawback in comparison to nginx modules: every middleware you want to use needs to be included into the binary and if it’s not, you need to re-compile the program (which is done for you by the download script at Caddy website, actually). GitHub Let’s Encrypt certbot middleware directives list of such JWT php-fpm I migrated all of my websites and -apps from nginx to Caddy (which took me hardly more than an hour) and so far I’m happy with the setup. But what about performance? To measure a very basic performance benchmark, I took , which I used in . This script uses the load test tool and I adjusted the parameters in a way that it performs a total of against a specific route at my webserver with a number of (each performing 3,125 requests) on . I ran both servers with almost their default configuration, except that I turned on HTTP/2.0 with a self-signed certificate. The file served was a static HTML file containing 6.2 kBytes of data. Both h2load and the respective web server were executed locally on the same machine with the following specs. this script an earlier benchmark scenario h2load 100,000 requests 32 concurrent clients 4 CPU threads ===CPU:model name : Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz cpu cores : 2 model name : Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz cpu cores : 2 model name : Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz cpu cores : 2 model name : Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz cpu cores : 2 ===RAM:total used free shared buff/cache available Mem: 7,7G 1,8G 4,2G 316M 1,6G 5,3G Swap: 29G 0B 29G ===OS:Linux ferdinand-ubuntu 4.8.0-32-generic #34-Ubuntu SMP Tue Dec 13 14:30:43 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux The results look like this. Caddy vs. nginx performance comparison As you can clearly see, nginx still performs way better, at least in this very simple scenario. However, Caddy is much more easy to use, in my opinion. Seems like we are having a classical trade-off here. Anyway, you should really give Caddy a try (and I’m not getting paid for this 😉). Concerning memory usage: I didn’t observe that in detail, but suprisingly I found that neither the Caddy process nor the sum of nginx worker processes exceeded 10 MB of RAM usage (may I have done something wrong?). Please note that I only measured one specific figure (concurrent req/s) in one specific scenario. One can think of other benchmark setups where results might be the complete opposite, potentially. By the way, Apache2 was not included to this benchmark, because I wanted to use HTTP/2.0. Actually in the meantime there is a for Apache2, but it's not included in the majority of the builds, yet, and to be honest, I didn't want to make an own one. If you're interested in that, you can get a rough idea of Apache2 vs. nginx performance in (spoiler: it's pretty poor). mod_http2 this article So to conclude the discussion: Should you use Caddy in preference to nginx or Apache2? For private projects definitely yes, if you ask me. For more projects you should probably wait until it’s even a little more mature (e.g. when a 1.x.x version is out) and maybe also incorporating dynamic module loading. Until then I’d stick with nginx. Besides that I can’t figure out a reason for preferring Apache2 over nginx, except for being too lazy to do the migration. serious Please let me know if you liked my article and also if you don’t agree with some of my arguments and insights. Originally published at ferdinand-muetsch.de .
