https://redmine.lighttpd.net/https://redmine.lighttpd.net/favicon.ico?13667327412009-03-22T21:30:27Zlighty labsLighttpd - Bug #1946: Enabling server.kbytes-per-second disables max-read/write-idlehttps://redmine.lighttpd.net/issues/1946?journal_id=57282009-03-22T21:30:27Zicy
<ul><li><strong>Target version</strong> changed from <i>1.4.22</i> to <i>1.4.23</i></li></ul> Lighttpd - Bug #1946: Enabling server.kbytes-per-second disables max-read/write-idlehttps://redmine.lighttpd.net/issues/1946?journal_id=57292009-03-22T21:31:54ZDelphy
<ul><li><strong>Target version</strong> deleted (<del><i>1.4.23</i></del>)</li></ul><p>Affected version is 1.4.22.</p> Lighttpd - Bug #1946: Enabling server.kbytes-per-second disables max-read/write-idlehttps://redmine.lighttpd.net/issues/1946?journal_id=57302009-03-22T21:35:22Zicy
<ul><li><strong>Target version</strong> set to <i>1.4.23</i></li></ul> Lighttpd - Bug #1946: Enabling server.kbytes-per-second disables max-read/write-idlehttps://redmine.lighttpd.net/issues/1946?journal_id=57472009-03-26T21:47:27Zstbuehler
<ul></ul><p>The code itself looks basically fine; we guess the problem is that the server load is too high to get back to normal, i.e. the limit is hit too early, and some connections never are allowed to send content again.</p>
<p>You could either try to lower buffer limits (sysctl net.ipv4.tcp_wmem), so lighty cannot send too much data on one connection, so more connection have the change to send something before the limit is hit, or try lower per-connection limits or use a lower max-connections limit.</p>
<p>If the connections don't even vanish if the limit isn't hit anymore, that would be a bug we may be able to fix - but i don't think that is the case.</p> Lighttpd - Bug #1946: Enabling server.kbytes-per-second disables max-read/write-idlehttps://redmine.lighttpd.net/issues/1946?journal_id=57582009-03-26T23:25:35Zpeto
<ul></ul><p>I've found that the rate limiting doesn't work terribly well: it's not very fair (buffer up some connections a lot, and give little or nothing to others), and the 1sec interval makes it very chunky, so if you're at the limit, a connection that wants to download a 1k JSON request will often sit around for a full second while transmissions are disabled.</p>
<p>It's probably sufficient for quickly limiting a personal server that only a few people will use, but for an active website this is really the job of kernel (or router) QoS. It has much more control, since it operates after TCP buffering, instead of before, and will probably be much more responsive. Also, you want limits to be per-IP, not per-connection, so you don't encourage people to abuse parallel downloaders to get a bigger chunk (userspace could do this, but I'm pretty sure lighttpd doesn't) ...</p> Lighttpd - Bug #1946: Enabling server.kbytes-per-second disables max-read/write-idlehttps://redmine.lighttpd.net/issues/1946?journal_id=57592009-03-26T23:43:29ZDelphy
<ul></ul><p>I think stbuehler is right - some kind of other server load was affecting this. Since I dropped the kbytes-per-second down from 4000 to 3500 it's been a lot better - not perfect but much much better than before. So it's obviously only able to work up to a server load limit point.</p>
<p>You can go ahead and close this bug now.</p> Lighttpd - Bug #1946: Enabling server.kbytes-per-second disables max-read/write-idlehttps://redmine.lighttpd.net/issues/1946?journal_id=57602009-03-26T23:53:34Zicy
<ul></ul><p>Sorry for abusing this ticket but I couldn't find any other way to message you Peto.<br />I always find your comments insightful and worthy.<br />Do you want to join us on IRC and maybe become a dev? I think the project could benefit from your contributions :)</p> Lighttpd - Bug #1946: Enabling server.kbytes-per-second disables max-read/write-idlehttps://redmine.lighttpd.net/issues/1946?journal_id=57612009-03-27T00:00:18Zstbuehler
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Wontfix</i></li></ul><p>Hm, this bug is neither invalid nor fixed - so i close it as wontfix, as i don't see how we could this better without recoding lighty from scratch (we already do that anyway :) ).</p>
<p>I basically agree with peto: the kernel has probably better ways to this. But there are some cases where you would want different limits/"pools" for different connections depending on the request. So it would be nice if lighty could do better here.</p> Lighttpd - Bug #1946: Enabling server.kbytes-per-second disables max-read/write-idlehttps://redmine.lighttpd.net/issues/1946?journal_id=57692009-04-03T06:23:03Zpeto
<ul></ul><p>If you want high-quality rate limiting and also to tune the limiting based on aspects of the request which are only available by understanding the HTTP request (and are therefore lighttpd's job), it's tricky. In theory, you can set flags on the TCP connection to pass along specific bits of information to the kernel (eg. priority), though pipelining would make this a little fuzzy and I've never tried it at this level.</p>
<p>icy: Maybe I'll drop in, but I have too many projects, and with most of my patches sitting around indefinitely as is, I don't feel very motivated...</p>