good ideas, thanks.
as someone said its cloggage on the backend due to either
SQL server contention or more likely largish pages draining
to the user even with all the buffers en-route helping to
mitigate this. you can't win : if they are on a modem they can
tie up 8 modperl demons, and if they are on a cable modem they
can disrupt your SQL server creating select/insert locks and
yet more stalled stuff. A cable modem, user could request
1mbit/s of dynamic content.. thats a big ask..
Since the clogging is not images (that is hopefully handled by
an image server like mathopd), its modperl pages, I'm going to
try a timed ban triggered by parallel requests from a single IP.
And yes it does happen often enough to annoy.. (often might be
two or three times a day even though as a percentage of uniques
its very tiny) since many of the culprits don't even know what
they've got installed on their PCs and are on dhcp addresses
and probably never return anyway IP bans after the event are
never any good and may hit the next user who picks up the IP.
-Justin
On Thu, Jun 07, 2001 at 07:34:45PM -0700, Randal L. Schwartz wrote:
> >>>>> "Justin" == Justin <[EMAIL PROTECTED]> writes:
>
> Justin> Does anyone see the value in a Throttle module that looked at
> Justin> the apache parent status block and rejected any request where
> Justin> another child was already busy servicing *that same IP* ?
> Justin> (note: the real IP is in the header in a backend setup so it
> Justin> is not possible to dig it out across children without
> Justin> creating another bit of shared memory or using the filesystem?).
>
> Justin> I'm still finding existing throttle modules do not pickup and
> Justin> block parallel or fast request streams fast enough .. ok there are
> Justin> no massive outages but 10 seconds of delay for everyone because
> Justin> all demons are busy servicing the same guy before we can conclude
> Justin> we're being flooded is not really great.. modperl driven forums
> Justin> (or PHP ones even) can be killed this way since there are so
> Justin> many links on one page, all active..
>
> It would be pretty simple, basing it on my CPU-limiting throttle that
> I've published in Linux Magazine
> <http://www.stonehenge.com/merlyn/LinuxMag/col17.html>. Just grab a
> flock on the CPU-logging file in the post-read-request phase instead
> of writing to it. If you can't get the flock, reject the request.
> Release the flock by closing the file in the log phase.
>
> But this'd sure mess up my ordinary visit to you, since my browser
> makes 4 connections in parallel to fetch images, and I believe most
> browsers do that these days.
>
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
> <[EMAIL PROTECTED]> <URL:http://www.stonehenge.com/merlyn/>
> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
> See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
