Feature #57

more flexible bandwidth limiting (like Apache mod_bandwidth/mod_throttle)

Added by Anonymous about 13 years ago. Updated over 9 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Missing in 1.5.x:


I would like to limit my outgoing bandwidth by specifying policies on different levels:
  • per-directory
  • per-virtualserver
  • per-user

In example:

users who match pattern would have 10kb/s output max, and users using would have 20kb/s at max.

It's basicly the same as in Apache's mod_bandwidth.

-- Louis

Associated revisions

Revision 8e3c6bf7 (diff)
Added by gstrauss almost 2 years ago

fallback to lseek()/read() if mmap() fails (#fixes 2666)

fallback to lseek()/read() if mmap() fails (#fixes 2666)
e.g. when mmap() is used on lighttpd-controlled temporary files
used POST request body (mod_cgi) and PUT file upload (mod_webdav)

replace use of stream_open() on potentially untrusted files
(protect against SIGBUS if a file is modified while map is read)
Note: stream.[ch] may be removed in a future release
For now, stream.[ch] will read entire file into memory if mmap fails
and so it should only be used on trusted files, e.g. config files.

http_auth basic and digest files are typically small and so buffered
stdio fopen(), fgets(), fclose() will likely be approximately as fast
as mmap.

mod_dirlisting header and readme files are typically small and so
open(), read(), close() will typically be approximately as fast as mmap

mod_ssi will likely be much faster, now buffering SSI page construction
rather than a potentially huge number of file open() calls, one for each
tiny chunk of text between SSI directives.

mod_webdav COPY and MOVE may be slower due to removal of mmap, but are
now more resilient to partial writes.

"handle filesystems without mmap() support"
"WebDAV upload-> mmap failed: operation not permitted"
"Lighttpd 1.4.20 Crash (SIGBUS in mod_compress)"
"Crash SIGBUS"

github: closes #57



Updated by conny about 12 years ago

The question is how different people define "_user_": does that refer to a virtual site, a local userid, a remote authenticated user, or the remote IP address?


Updated by conny about 12 years ago

Note: Related but not entirely the same is the principle of simple per-remote-IP concurrency limits, like those made available for Lighttpd by source:browser/branches/lighttpd-merge-1.4.x/src/mod_evasive.c#896.


Updated by stbuehler over 9 years ago

  • Status changed from New to Fixed
  • Resolution set to wontfix

connection.kbytes-per-second should basically do what you want for directory and vhost, evasive.max-conns-per-ip for user.


Updated by stbuehler over 9 years ago

  • Status changed from Fixed to Wontfix

Also available in: Atom