My startup uses Lighttpd and Nginx, but I tossed in one Other vote for my use of Cherokee on some small personal things. For instance, I'm using Cherokee + uWSGI + poit to run my own OpenID provider.
Beware! For the (currently 3) Node.js users, realize that Ryan Dahl (author) recently said that Node.js should not be directly exposed to the public Internet at this time.
www.unscatter.com is using nginx for load balancing and soon for static content. You might want to add Tornado as an option as well, as that's the web servers that nginx is proxying in my case. Plus, I'd be curious to see how many others are using Tornado.
I am currently using Apache and its the only web server I ever used, I have looked in to Lighttpd and Nginx but never actually used it. Can anyone tell me why I should use the other two over Apache? The main reason I am using Apache because it has a large user base, community and documentation that I can rely on if I ever need any help.
Can't vouch for lighty (though I suppose the same applies) but nginx is much, much faster than Apache. nginx was designed with speed in mind, Apache with reliability[1] and extensibility.
[1] Apache's internal API is designed to make it difficult to leak memory or other resources, overrun buffers, etc.
The main reason I switched to Nginx is that it uses dramatically less memory than Apache. Running a semi-popular message board, I was eating through 4Gb of memory between Apache and MySQL on Ubuntu, and simply switching over to Nginx was faster and freed up over 1Gb of allocated memory immediately.
Since then, I've grown to dramatically prefer its configuration file syntax and usability.
But note that Apache's memory use (and overal slowness) depends a lot on what modules you use. mod_{php,perl,...} embeds a whole interpreter in each Apache process, which causes lots of overhead, but you don't have to use these.
I switched to nginx because it was leaner than apache, and the specific use case I had for it was load balancing (and eventually proxy caching) and static content. Apache is great because of the amount of options it has, it's the swiss army knife of web servers. However, if you really don't need your web server to do a lot, I've found that other systems are a more efficient choice, especially when you're trying to squeeze a lot out of small VPS machines.
To add to the responses below, my sites are done with Rails, which tends to want to do things inside of Rails itself, rather than use features of the web server. All I want out of a server is to manage incoming requests and route them to Unicorn. So the large featureset of Apache is a downside, and the leanness of nginx is an upside.
When choosing between Apache and Nginx (or others), it's not really an apples-to-apples comparison, so you better look at the feature-set carefully before you choose to move. Apache has tons of features and has a great ecosystem around it, which means it can do a lot more to help you generate the content you need - e.g. server-side processing. Nginx is more geared towards high-performance, yet simpler content serving needs. Identify your needs, and then choose.
In a nutshell, if you are using mod_php, mod_perl or any of the esoteric modules with Apache in your current installation, I think staying with httpd is a better idea. If you are facing performance problems, you could use Nginx as a reverse-proxy.
I was using Nginx for static files and a reverse proxy (+balancer) to CherryPy until recently. Now switched to Nginx + uWSGI for everything and couldn't be happier. Nginx is very fast, even when on-the-fly Gzip is enabled.
Basically I was running CherryPy with supervisord+memmon since the application is a bit faulty. uWSGI alone can replace the whole stack: it comes with its own process manager, memory monitor and has Harakiri mode to monitor a process that is taking too long to response.
Initial setup was super tricky (Nginx in FreeBSD port doesn't ship with uWSGI support and XML config somehow doesn't work, so I have to use Python config which the documentation is lacking) but it has been doing its job ever since.
uWSGI is fast, has low memory footprint (a bit above Gevent/FAPWS) and is very reliable by itself. I'd recommend you to at least try it. The uWSGI documentation[1] was what got me interested.
Lighty, Apache and Nginx have been tested much better to face the wild public, hunchentoot not so much.
Hunchentoot's builtin multiplexer is one thread per connection, or one process for all incoming connections: you can customize the taskmaster to be event driven, but then, you will have to write your own load-balancing cruft code to distribute load between processes; something you get for free with a proxy.
It's a "hidden" feature because of the potential for abuse, and the fact that polls are generally uninteresting and low signal-to-noise. The expectation is that people who've been here for a while will know polls exist and be able to figure out how to make one, while new folks who haven't quite grasped the high signal-to-noise and very focused nature of the site won't know it's possible.
For my Ajax apps I run nginx and Apache simultaneously. I don't like giving up Apache's module-based performance advantages for the application layer, but its memory usage is too high for my VPS if I want to use KeepAlive. I use nginx as the front-line web server and configure it to serve pre-gzipped static content and maintain KeepAlive connections. It then proxies dynamic requests to the Apache server. All makes for a nice low memory footprint :)
80 comments
[ 2.5 ms ] story [ 205 ms ] threadApache on the back end as I'm comfortable tuning it.
http://developer.yahoo.com/yui/theater/video.php?v=dahl-node
I retain a lingering fondness for dan bernstein's publicfile http://cr.yp.to/publicfile.html but don't actually use it.
Easier to configure, can handle high loads with a lot less resources, more verbose configuration.
All 3 are a reasonable choice though.
[1] Apache's internal API is designed to make it difficult to leak memory or other resources, overrun buffers, etc.
Since then, I've grown to dramatically prefer its configuration file syntax and usability.
In a nutshell, if you are using mod_php, mod_perl or any of the esoteric modules with Apache in your current installation, I think staying with httpd is a better idea. If you are facing performance problems, you could use Nginx as a reverse-proxy.
LLWP (Linux, Lighttpd, Werc, Postgresql)
I might change Werc to Go on the next project.
Is IIS 7.5 closer to those targets?
I'm a few days late on this, but curious: by what measure(s) do you mean that?
Initial setup was super tricky (Nginx in FreeBSD port doesn't ship with uWSGI support and XML config somehow doesn't work, so I have to use Python config which the documentation is lacking) but it has been doing its job ever since.
uWSGI is fast, has low memory footprint (a bit above Gevent/FAPWS) and is very reliable by itself. I'd recommend you to at least try it. The uWSGI documentation[1] was what got me interested.
[1]: http://projects.unbit.it/uwsgi/wiki/Doc
(By the way, I use a patch on this Chinese blog: http://www.indexofire.com/blog/?p=605 to build Nginx with uWSGI support on a FreeBSD. I made this: http://aur.archlinux.org/packages.php?ID=37857 for running on Arch. /shameless plug)
antiweb (hoytech.com/antiweb) also looks promising, but I haven't put anything into production with it yet.
Hunchentoot's builtin multiplexer is one thread per connection, or one process for all incoming connections: you can customize the taskmaster to be event driven, but then, you will have to write your own load-balancing cruft code to distribute load between processes; something you get for free with a proxy.