nginx vs lighttpd

scs653298

　　I have been using Lighttpd for almost a year and Nginx for a month on my servers. I know that they were created to be massively scalable, solving the C10k problem. However their asynchronised-IO model and small memory foot-print also make them suitable as alternative HTTP servers for memory-limited VPS. Alternative = Anything but the current defacto Apache.
　　I will be writing more about Lighttpd and Nginx later during the year, but will try to use this post to draw some comparison between Nginx, the new darling of these light-weight web servers, and Lighttpd, many Web 2.0 developers’ all time favourite.
Lighttpd

http://hostingfu.com/files/images/light-logo.png I have been running Lighttpd (pronounced “lighty”) on my home servers and development boxes since the beginning of 2006. It is a great replacement for Apache if you have the whole box to yourself, i.e. you don’t need to worry about supporting .htaccess files that your users might use. Currently this website is hosted on lighttpd-1.4.13 on a Gentoo VPS.

　　Pros

• Light weight. Clean restart of 1.4.13 takes no more than 2Mb RSS on this 64bit VPS. It binds the port, drops the privilege and that’s it! A single process does all the tricks even when you have hundreds of concurrent connections. No more pre-fork MPM with mis-configured MaxClient that sends you to swap hell.
  
• Speed. Very fast static file serving. Very fast FastCGI serving. Very fast proxy serving.
  
• Modules, and lots of them. Good comprehensive documentation as well. It even has SCGI for your Quixote apps.
  
• Mod_magnet. Wanna a scripting engine right inside your web server? Mod_magnet integrates Lua into lighttpd, so your World of Warcraft scripting skillz can be put into better use.
  
• Community. It has got a Blog, a Wiki/bug tracker and a forum. It is easy to find help when you need one.
  

　　Cons

• Stability (or lack of according to the RoR folks). I had quite a lot of issues using Lighttpd as proxy+HTTPS front-end for our Python stuff, but the same app runs fine with just lighttpd + proxy without HTTPS.
  
• Mod_rewrite (or again, lack of it). Built-in rewriting engine sucks, and porting Apache mod_rewrite rules over can be non-trivial sometimes. Update: Here’s an article I have written on Drupal clean URL on Nginx and Lighttpd, which looks at the URL rewrite options of these two web servers.
  
• Memory leak. The RSS of my lighty process grows by about 1.5Mb per day, but then I don’t have lots of traffic (less than 50k requests a day). At the end I just need to restart it once a week. Many people have far worse memory leaking issues I heard.
  

Nginx

http://hostingfu.com/files/images/nginx-logo.png I have been running Nginx (pronounced “engine X”) on my development box and two of my VPS’s since December 2006. It is Russian, fast and very configurable. I am currently using 0.5.5 for my sites, but don’t be deceived by its version number — it is very stable.

　　Pros

• Light weight. It is not as light weight as lighttpd when it clean-starts. At least two processes are needed — one master process running as root that binds to the port, and one or more worker processes that handle the actual requests. Around 7Mb RSS together on my 64bit VPS (and only 4.5Mb on 32bit VPS). Still beats Apache hands down.
  
• Fast. Some benchmarks have shown that Nginx has a slight edge over Lighttpd, but so far I haven’t been able to notice any. Again, much faster than Apache over static file serving or proxying, especially when you turn up the value of keep alive (more than 1 minute for example).
  
• Modules. There are many modules available on Nginx. Some very useful, and some are just plain weird. While lighttpd has Lua embedded, you can now also embed the whole Perl interpretor inside Nginx.
  
• Better Rewrite Module. A much better rewrite module than Lighttpd that supports complex conditions. Porting mod_rewrite rules from Apache is actually now feasible without touching the apps themselves.
  
• Stable and not leaking. Been running Nginx on a production site doing PHP-FastCGI, and have no issue what so ever.
  

　　Cons

• Lack of community. Where can I find help regarding Nginx? There’s only IRC as far as I know. And while the lead developer writes beautiful code, all documentation were initially in Russian which was a big stumbling block before the English docs came along.
  
• No CGI support. Oh well, maybe I am the only one who still hacks small CGI scripts. Apparently Nginx does not spawn CGI or FastCGI processes, which means you need to either (1) convert it into external-spawn FastCGI, or (2) proxy to another web server that does CGI.
  
• No simple virtual host support. Lighttpd has mod_simple_vhost and mod_evhost to let you quickly deploy lots of name-based virtual hosts. You can somehow do the same with using $server_name in root and a wild-card in server_name, but it’s still not as clean as lighttpd. At the end you will find Nginx configuration files much more verbose if you run lots of small sites off a single web server.
  
• No X-sendfile support. I found Lighttpd’s X-sendfile support very useful when my scripts need to send back large files, and was disappointed to find out that Nginx does not have it. X-Accel-Redirect is different as it requires extra configuration on web server, which makes your web-app less portable.
  

Conclusion
　　I don’t think I am a suitable judge to say which one is better, as (1) I have only been running Nginx for a month, and (2) my level of traffic does not really stress test these high-performing web servers. At the moment I think I like Nginx better purely because it does not leak, and its rewrite module that enables me to run many off-the-shelf open source PHP apps with clean URL.
　　Again, I might change my mind in 3 months time when I find out more warts about Nginx. We will see.