lighttpd seems to enqueue all new incoming FastCGI requests so that every single request is processed one time. This works very well while FastCGI processes handle incoming requests in a moderate time. But if the machine is under high load and FastCGI processes need a long time to proceed, the load increases dramatically since (I guess) lighttpd hands over requests, that were already aborted by the requesting browser. Since processes take a long time to complete a request, users may (and they do) visit another link on the server, aborting the previous request - but FastCGI will still process this aborted request.
I know, a webserver should never be under that high load, but if it comes to this, the system load seems to explode.
I tested this by just hitting a link to delete some entries from a website using PHP with FastCGI on a very high load server...However, when I close the new browser window immediately, entries will be still deleted. In fact, no free FastCGI process was available at the time of the request and there still was none when the browser window was closed.
I think lighttpd would perform much better under that high load, if there would be an internal queue in lighttpd for fastcgi requests and an additional check if the connection of the request is still active before the requests will be processed by the next free FastCGI process.
*** Sorry for my bad english ;)
