Two of the most popular open-source HTTP servers are featured in todays ‘VS’. There’s some interesting facts about both, if you’re not familiar with either then it’s well worth a read.
Both Lighttpd and nignx are asynchronous servers.
Nginx and Lighttpd are probably the two best-known asynchronous servers and Apache is undoubtedly the best known process-based server. […] The main advantage of the asynchronous approach is scalability. In a process-based server, each simultaneous connection requires a thread which incurs significant overhead. An asynchronous server, on the other hand, is event-driven and handles requests in a single (or at least, very few) threads. […] Pulling numbers from thin air for illustrative purposes, serving 10,000 simultaneous connections would probably only cause Nginx to use a few megabytes of RAM whereas Apache would probably consume hundreds of megabytes (if it could do it at all).
Lighttpd runs as a single process with a single thread and non-blocking I/O.
nginx works as one master process but delegates its work unto worker processes.
One problem with Lighty is that it leaks memory like a sieve. I audited it for a little bit and I gave up, it’s a mess. I’d steer clear of it, it will quickly ruin your day if you throw a lot of traffic at it.
Nginx is noted to be a good server for sites that need fast, efficient reverse proxies or fast, efficient serving of static content. It is acclaimed for having low memory usage and is recommended for sites running on a VPS.
Both servers performed extremely well, though it seems that Lighttpd might perform best in a more fragmented file system (smaller files). Considering that each would easily saturate the pipeline I doubt a real-world performance difference would be seen.
Blog post comments support the fact that the difference in performance is negligible and indicate that nginx uses less CPU than lighttpd:
- in my simple stress tests cpu usage showed lighttpd at 98% while nginx was never more than 52%.
- Nginx performed almost the same as lighttpd but cpu load was much better with nginx. (LA never got more than 5 while lighttpd bumped it up to ~10, and apache to 20+ while testing with the wordpress setup) Btw, can’t even compare it to apache, which almost crashed my box when testing the sample wordpress install.( 10000 requests, 1000 concurrent)
- The difference in speed between lighttpd and nginx is really negligible, as you see nginx might outperform lighttpd on some workloads and vice versa with other workloads. What really matters is stability, CPU consumption, and ease of use. And nginx really beats lighttpd there – by far.
Lighttpd has had support for IPv6 for a long time.
IPv6 support for nginx is in the works.
Lighttpd has support for CGI, FastCGI and SCGI via modules. These backends, however, do not support large files. If you try to send large files, lighttpd will try to buffer them all in memory, even if they’re gigabytes in size and you don’t have that much memory to work with. This memory will generally not be returned to the operating system when you’re done with the transfer, either (though it may be reused).
Known issue, many reports, won’t fix in 1.x. Don’t send big files via proxy, cgi, scgi, …— stbuehler on lighty bug #1283
Lighttpd is capable of automatically spawning FastCGI backends as well as using externally spawned processes.
Nginx has native module support for FastCGI, SCGI, and uWSGI, and has support for WSGI via a 3rd Party module. A user must spawn the processes using php-fpm, which is now integrated in the php core, manually, or with an automated tool such as spawn-fcgi because nginx does not spawn fastcgi processes on it’s own. Nginx does not run plain CGI applications, which can actually be considered security benefit. Instead, you can use a perl script, or proxy to a simple web server that runs CGI such as thttpd.
Nginx’s HTTP proxy only talks HTTP/1.0 to a backend server and does not support keep-alive.
Nginx has built-in support to communicate directly with memcached. This is particularly useful for super-fast delivery of pages that are cached in memcached by a background process or a web application.
Lighttpd supports similar features through its mod_cml module.
X-Sendfile is a feature that allows scripts or web applications to send files on the filesystem that are restricted by the web server (nginx / lighttpd) by having the script send a special header.
Lighttpd accomplishes this by using the X-Sendfile header with an absolute file path. Nginx has a more restricted feature using the X-Accel-Redirect header that allows for relative file paths from a predefined location.
Separated error logging per virtual server
Lighttpd’s author intentionally refused to support this feature, despite user requests. Nginx supports separate error logging per virtual server.
Ease of use
If you need a simple HTTP server to serve some static files, Lighttpd has a very simple setup. With nginx, that’s much harder.
Lighttpd has been popular in the United States for longer than nginx and is known to have many modules.
Lately I’ve gotten fed up with Lighttpd. There’s been outstanding bugs that are so familiar they’ve acquired names. The project’s lead, Jan Kneche, seems more interested in schmoozing up to the Rails crowd than providing a decent product
The greatest hindrance for a wide adoption of nginx was a lack of English support. There has been much improvement in this regard, however, and there is now an English Wiki providing good documentation of nginx’s features, albeit suffering from bad English grammar and lack of structure and coverage.
Lighttpd has a full-blown bug tracking system powered by Redmine.
Nginx has a poor man’s bug tracking system in the form of a wiki page, which as of 2009-08-16, lists only one bug, dating from 2007-11-11.
New bugging sistem using trac
Both Lighttpd and nginx have IRC channels on the freenode.net server (#lighttpd and #nginx), but the nginx channel is very quiet, with long delays between responses to user questions.
According to the August 2010 Netcraft survey, nginx hosted about 5.49% of total number of domains while lighttpd hosted about 0.85% only.