Or just Apache. Apache serves static content faster than the vast majority of us will ever need, and dynamic content as fast as Lighttpd or nginx, in general (because the slow part is the code in Python, or PHP, or Ruby, or Perl). Run WSGI or mod_fcgid or mod_rails, or whatever, so your interpreter only spawns once, configure Apache appropriately, and you'll be fine for all but the most insane loads.
If I go with PHP, Apache will be running non-threaded.
To run Apache/PHP as lean as possible, I'll take advantage of thttpd's polling to quickly serve up any static content I have to as many simultaneous connections as possible.
I haven't taken a really deep look at lighttpd nor nginx.
I see what you mean though, why would I use two distinctly different http servers where one would simply do?
Could you give me some hints as to what I'm missing out on if I stay with Apache and thttpd or what I'd gain going to either nginx or lighttpd?
Apache buys you two things: rock-solid, time-tested stability, and millions of words of writing both online and in print about administration and tuning.
Lighty and Nginx are both (like thttpd) leaner, potentially faster, and "sexier." Neither has the proven stability or community that Apache does, and neither is going to help much if your bottlenecks are at the application layer, rather than just shooting raw bits over a network cable.
Neither has the proven stability or community that Apache does
I care about the community/support aspect and you're right; I think going solely with Apache, and skipping the leaner httpd engines, is definitely a possible choice for me.
Apache is probably better for people who want to worry about their app first and their infrastructure second. After your app is under control and you have time to worry about performance and configuration then you may want to look at the others.
Then there's also other servers like Squid and thttpd. If you don't know why you would want one of them then you're probably better off not thinking about them for now. To be honest I don't know what thttpd has going for it these days. A previous company I worked for standardized on it early on and then ended up adding so much to it they would have probably been better going with Apache.
