Feature #1451
closedQueuing requests to FastCGI backed rather then sending them.
Description
First of all see discussions there :
500 Errors on high concurrent load of multithreaded fcgi app
Lighttpd is capable of queuing request that sends to simple single threaded
FastCGI server, However this does not happens in case of multithreaded application.
If FastCGI application is capable of managing 10 requests on the single socket.
(Accepting maximum 10 requests for 10 threads), all other concurrent requests
will return Error 500 instead of being queued on Lighttpd side.
Thus option that limits maximal concurrent requests per single FastCGI server
required. Otherwise fastcgi application will have to manage the queue of incoming
request by itself, that is significantly less effective.
-- artyomtnk
Updated by gstrauss almost 8 years ago
- Description updated (diff)
- Category changed from core to mod_fastcgi
- Assignee deleted (
jan)
Updated by gstrauss over 7 years ago
- Priority changed from Normal to Low
With lighttpd 1.4.40 and later, lighttpd aborts connection to fastcgi backend if the client disconnects. (https://github.com/lighttpd/lighttpd1.4/pull/53). Also, lighttpd allows you to tune the socket listen backlog for backends separately from frontend connections (https://github.com/lighttpd/lighttpd1.4/pull/50) See also further discussion in #2116, #1825, #967, #641, #399
As suggested for mod_cgi in #2431
(If looking to arbitrarily limit the number of outstanding requests to backends, perhaps a more generic solution would be to write a module to allow URI paths to apply limits to number of outstanding requests waiting for backends for that URI path, and could return 503 Service Unavailable for any new requests to such a URI path comes in while the limit has been reached)Updated by gstrauss about 7 years ago
- Is duplicate of Feature #967: request-queue-limit option for mod_fastcgi added
Also available in: Atom