>>>>> "Jeffrey" == Jeffrey W Baker <[EMAIL PROTECTED]> writes:
Jeffrey> That's a nifty module. I suggest that you alter your
Jeffrey> threshold slightly. Instead of setting a fixed percentage of
Jeffrey> CPU time, you should also consider the overall load. I know
Jeffrey> I wouldn't care if one IP was taking up 5% CPU time if the
Jeffrey> overall load on the machine was less than 50% or so.
yes, that's on the "todo" list, but the problem is where to keep it.
It's a bit expensive to fetch, although I could argue no more
expensive than computing the CPU used within the window. :)
And the relationship between how much to give *this* person and the
loadav is not clear. If there are five people hammering your site,
you can give them each 20%. But how do you know there are 5 people
hammering... too much lateral state. I suppose you could slowly raise
the 5% figure until loadav was 0.95, then lower it if it got above,
but then you have interprocess communication to get right. :) And you
also don't want to get into feedback oscillation - after all, past CPU
is not necessarily a predictor of future usage. If the loadav is >1,
clearly the CPU limits are probably too high though... I'm just not
sure what to do about that. Maybe divide 5% by the loadav, and
presume an average of 20 concurrent heavy visitors. Or am I double
dividing here? Dunno.
Jeffrey> Also how does this IP-based tracking work in practice?
Jeffrey> People who are behind corporate firewalls present dual
Jeffrey> problems: one person can map to several IP addresses if the
Jeffrey> firewall uses a cluster of proxies, and one IP can map to
Jeffrey> many people. A serious throttling effort would need to take
Jeffrey> this into account.
Another todo item is research an IP-crossed-with-browser-useragent
approach, similar to Apache::Limit. I suppose it's unfair then to
everyone that uses the same browser type within a company. :) Maybe I
could use the cookie thrown up by mod_usertrack, but I don't have that
enabled here and don't want to require it.
Thank you for the feedback. I must be on the right track since you
talked about items I was already pondering. :)
--
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!
