On Wed, 22 Feb 2006, Paul Querna wrote:
> Brian Behlendorf wrote:
>> On Wed, 22 Feb 2006, Garrett Rooney wrote:
>>> It might be possible to do some magic in apache modules to make that
>>> work, but I'm not sure how off the top of my head. Would certainly be
>>> nice though.
>>
>> mod_throttle? mod_bandwidth?
>
> These existing modules wouldn't actually fix much, since they are generally
> designed to limit the number of concurrent requests, and/or bandwidth used,
> neither of which is causing the load problem.
Agreed on concurrent requests, but bandwidth used may be relevant, since
responding to a big request is a combination of server CPU time, local
disk I/O, and network I/O. If you rate limit network I/O to that
particular client, then you probably also effectively rate limit the other
two, since we're not pipelining at all yet, and even when we do there'll
be a limit to how deep the pipeline will go.
> One thing you can do, is drop the priority of the Subversion HTTPD Process,
> so it doesn't starve the machine for IO and CPU.
What about a multithreaded httpd? Is there a cross-platform way to drop a
priority of a thread?
It seems like there are two responses to an "abusive request": to
either reject it or to allow it to progress in a way that does not
interfere with others. In the first case, Garrett's idea to filter the
REPORT mechanism might work, or it might simply be a question of how
flexible we make ACLs and authz. In the second case, this is a very
familiar topic in operating systems design (how to keep one process from
soaking up so much time that it "unfairly" robs other processes of the
right to complete). I'm tempted to say let's let the OS worry about the
problem by using POSIX or OS-specific semantics where possible to rate
limit or lower priority of the responding thread, making sure we don't
exacerbate the problem in some way (like exclusive lock during read).
Overall I'd say let the administrator decide which of those two approaches
to take.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 23 18:07:18 2006