Performance benefits of running Lighttpd (or other non-Apache servers)?

People get frustrated with how much memory Apache takes, and switch from mod_php to FastCGI, then explore Lighttpd, then the memory leaks become troublesome, then they try nginx, then ....

Finally, they come back to Apache to mod_php, which is the most stable and feature rich.

I have seen this pattern a few times. Even Drupal.org used to run under FastCGI, now is back to mod_php.

Would like to know from those who have stuck to lighty or ngnix how they are doing and whether they will persevere.

Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.

For several of our larger-scale sites, we have deployed the commercial Zeus Web Server (ZWS) with a bunch of FastCGI processor machines that run behind a load balancer. Files shared over NFS, MySQL on a separate server(s). Works like a charm, no stability/memory/leak/etc issues what-so-ever, and to scale up we just add more processing servers.

We definitely ran into lock-up/runway process issues with Apache and FastCGI. YMMV.

Not sure what advantage going with mod_php would really provide, although there are some advantages (KISS) to load balancing "just" HTTP traffic rather than remote FastCGI requests on the back end.

No matter what you use, ensure that your Apache processes are lean. No sense in creating more process overhead.

I've been using lighttpd for almost 2 years and I was quite happy with it.

Yes, there have been quite a few memory leaks, but the current stable (1.4.19) seems to have no such problem (or at least not a major one). Another thing is that there is no check for 'if file exists' in rewrite rules and you have to use mod_magnet slightly reducing performance or create some really strange and complex (compared to apache & nginx) rewrite rules.
Also there is no graceful restart - there is no way to reload configuration without restarting lighty, which if you allow lighty to start it's own fastcgi processes means all php-cgi processes get killed and started again with all the consequences (like APC/xcache/etc having to rebuild oo cache).

All this is just nuisance and I would have stayed with lighttpd if it was all - the performance advantage over Apache is huge, especially if run with Fam/Gamin. The one thing that forced me to move to nginx is the limited ability of lighttpd to recover after MAJOR traffic spike. If there is enough traffic to overload all php-cgi processes it is very likely that.. server load will drop to near zero and only static content will be served until both lighttpd and all fastcgi processes get manually killed (with kill -9 - anything less wouldn't work) and then started again. This happened to me twice from the very beginning with lighty to about 3 months ego. Then a bunch of script kiddies started sending up to 2000 requests per second in batches lasting 2-3 seconds - it was enough to kill 4 core server each time and it stayed dead until it was lighty and fastcgi was killed -9 and started again. There was absolutely nothing I could do to prevent it (each request was from a separate IP - they were using zombified PCs) - automatic detection & restart wasn't really a solution, but got 95% angry users of my back for just long enough for me to learn how to use nginx.

After 3 months with nginx I can say that:
- it is faster than lighty -the difference isn't big, but it's there
- it has a steeper learning curve than lighty and there is almost no community help available - even documentation in english is a very recent thing! (when I started with lighty nginx documentation was russian only)
- rewrite rules are less complex compared to apache (in simple cases) and can be really complex if you want to (meaning you do get A LOT of options you can really use if you want to) - and you get 'if the file exists' check
- rewrite rules parser only stops on obvious and very serious mistakes - if writing a more complex set of rules you will spend quite a while trying to figure out why X doesn't work if no error was reported (and usually find out that rule was simply and quietly ignored due to errors)
- graceful restart is absolutely fabulous. Not only you can reload configuration without restarting, you can even replace nginx binary without having a 1 millisecond downtime
- it finally is easy to set all the server-side stuff that yslow was moaning about

Isn't varnish a reverse proxy? If I were to include reverse proxies as well I'd have to test at least squid, pound and nginx in reverse proxy configuration. That would be almost 600 different tests. Unless I design some kind of automation to perform the tests and gather results proxies will have to wait.

Another argument against testing reverse proxies it that I have very little experience with them and my misconfiguration is very likely to change the results. Luckily that is not the case with all software mentioned in previous post.