https://redmine.lighttpd.net/https://redmine.lighttpd.net/favicon.ico?13667327412008-03-19T21:29:17Zlighty labsLighttpd - Feature #967: request-queue-limit option for mod_fastcgihttps://redmine.lighttpd.net/issues/967?journal_id=22832008-03-19T21:29:17ZAnonymous
<ul></ul><p>I modified the patch to work with 1.4.19 Debian package. Should also work with other distros / upstream lighttpd though.</p>
<p>Just copy it into debian/patches/20_request-queue-limit.patch and add the name to debian/patches/series</p>
<p>-- Tom Fernandes <anyaddress</p> Lighttpd - Feature #967: request-queue-limit option for mod_fastcgihttps://redmine.lighttpd.net/issues/967?journal_id=87932016-02-15T18:09:31Zgstrauss
<ul></ul><p>Very old ticket marked high priority.</p>
<p>At first glance, it still seems like a good idea to add an option limiting the outstanding load on a backend.</p>
<p>However, this solution is only accurate when there is a single, frontend web server, since the load count is maintained locally. Having multiple server.max-workers, or separate frontend servers renders inaccurate the load count of backend servers because the counts are maintained independently on each frontend server. A better solution would be at the backend FastCGI source, though I realize that a typical, simple backend FastCGI server processes requests serially, relying on the listen backlog queue for queue management.</p>
<p>This patch is still useful for the use case where there is a single frontend web server in front of a pod of FastCGI servers, including the case where there is a load balancer in front of many frontend web servers, with each frontend web server relaying requests back to a set of FastCGI backends exclusively dedicated to that one, frontend web server.</p>
<p>Would the patch be acceptable along with an update to the documentation with usage caveats mentioned above?</p> Lighttpd - Feature #967: request-queue-limit option for mod_fastcgihttps://redmine.lighttpd.net/issues/967?journal_id=91342016-03-19T12:09:39Zstbuehler
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/9134/diff?detail_id=7084">diff</a>)</li><li><strong>Assignee</strong> deleted (<del><i>jan</i></del>)</li><li><strong>Priority</strong> changed from <i>High</i> to <i>Normal</i></li></ul><p><a class="user active user-mention" href="https://redmine.lighttpd.net/users/10519">@gstrauss</a>: No promises on review time.</p> Lighttpd - Feature #967: request-queue-limit option for mod_fastcgihttps://redmine.lighttpd.net/issues/967?journal_id=94832016-04-28T05:41:51Zgstrauss
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-4 priority-default closed" href="/issues/2431">Feature #2431</a>: mod_cgi process limit</i> added</li></ul> Lighttpd - Feature #967: request-queue-limit option for mod_fastcgihttps://redmine.lighttpd.net/issues/967?journal_id=94892016-04-29T16:46:51Zgstrauss
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>Low</i></li></ul><p>recent commits lower the priority of this specific feature request.</p>
<p>With recent commits, if the client disconnects, lighttpd now cancels fastcgi requests that have not yet been sent to the backend. (<a class="external" href="https://github.com/lighttpd/lighttpd1.4/pull/53">https://github.com/lighttpd/lighttpd1.4/pull/53</a>). Also, lighttpd allows you to tune the socket listen backlog for backends separately from frontend connections (<a class="external" href="https://github.com/lighttpd/lighttpd1.4/pull/50">https://github.com/lighttpd/lighttpd1.4/pull/50</a>) See also further discussion in <a class="issue tracker-1 status-5 priority-5 priority-high3 closed" title="Bug: FastCGI performance on high load (Fixed)" href="https://redmine.lighttpd.net/issues/399">#399</a>, <a class="issue tracker-2 status-5 priority-3 priority-lowest closed" title="Feature: add server.listen-backlog option instead of hard-coded value (128 * 8) for listen() (Fixed)" href="https://redmine.lighttpd.net/issues/2116">#2116</a>, <a class="issue tracker-1 status-6 priority-4 priority-default closed" title="Bug: Don't disable backend when overloaded (Invalid)" href="https://redmine.lighttpd.net/issues/1825">#1825</a></p>
<p>As noted for mod_cgi in <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: mod_cgi process limit (Fixed)" href="https://redmine.lighttpd.net/issues/2431">#2431</a></p>
<blockquote>
<p>(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)</p>
</blockquote> Lighttpd - Feature #967: request-queue-limit option for mod_fastcgihttps://redmine.lighttpd.net/issues/967?journal_id=107942017-01-21T02:06:16Zgstrauss
<ul><li><strong>Has duplicate</strong> <i><a class="issue tracker-2 status-10 priority-3 priority-lowest closed" href="/issues/1451">Feature #1451</a>: Queuing requests to FastCGI backed rather then sending them.</i> added</li></ul> Lighttpd - Feature #967: request-queue-limit option for mod_fastcgihttps://redmine.lighttpd.net/issues/967?journal_id=107962017-01-21T02:22:56Zgstrauss
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-4 priority-default closed" href="/issues/1530">Feature #1530</a>: cgi.max_processes addition</i> added</li></ul> Lighttpd - Feature #967: request-queue-limit option for mod_fastcgihttps://redmine.lighttpd.net/issues/967?journal_id=110632017-07-15T23:48:09Zgstrauss
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Fixed</i></li><li><strong>Target version</strong> set to <i>1.4.x</i></li></ul><p>Since lighttpd 1.4.40, the <code>"listen-backlog"</code> attribute of each host in <code>fastcgi.server</code> will create listening socket for each backend process with that socket connection queue limit.</p>
<p>If lighttpd does not start the backend, then it is up to whatever starts the backend FastCGI process to set the connection backlog limit on the listening socket.</p>