httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, VF-Group <>
Subject Re: [PROPOSAL] merge mod_limitipconn into httpd
Date Fri, 20 Jun 2008 09:25:26 GMT

> -----Ursprüngliche Nachricht-----
> Von: Niklas Edmundsson  
> Gesendet: Freitag, 20. Juni 2008 11:22
> An:
> Cc: David Jao; Ian Holsman (Lists)
> Betreff: Re: [PROPOSAL] merge mod_limitipconn into httpd
> On Thu, 19 Jun 2008, David Jao wrote:
> > Ian Holsman (Lists) wrote:
> >> My only concern with the module is that it can't be used 
> across servers.
> >> So I am not sure how useful it would be non-trivial sites. with
> >> stateless load balancing. (where the IP is not guaranteed 
> to visit the
> >> same machine for the next request)
> > Even without shared state, one can still enforce crude limits by
> > configuring a limit on each individual server.  For 
> example, if you are
> > load balancing across five machines, and each machine has a 
> limit of 2,
> > then the farm as a whole has a limit of 10, which is not great, but
> > still better than nothing (IMO anyway).  If you have a 
> million machines,
> > then this won't work, but at that point you probably have 
> enough money
> > to solve this problem some other way.
> I agree. The module isn't (currently) designed to be a precise 
> instrument, but rather to enforce an absolute maximum, and as such it 
> does its job while keeping the module relatively simple. For example, 
> our usecase on is setting a limit of 10 on each of our 
> frontends. It doesn't matter much that it sums up to quite a 
> lot while 
> adding up all frontends, because we just want to put a hamper on the 
> most blatant abuse by download-agents that makes a single server run 
> into MaxClients...
> It can surely be improved, but I also have the gut feeling that we 
> should aim at keeping this simple and let the more ambitious projects 
> handle complex stuff like shared state and so on.
> In its current form mod_limitipconn is a simple module which won't 
> need much maintenance, and as such it could be added to httpd without 
> causing much work for the committers. If it had been complex and 
> requiring much maintenance I doubt that I would have proposed 
> to merge 
> it into httpd in the first place...




View raw message