httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Axel-Stéphane SMORGRAV <Axel-Stephane.SMORG...@europe.adp.com>
Subject RE: [PATCH] Apache 2.2.x: Implicit creation of new proxy_workers
Date Wed, 12 Sep 2007 07:30:45 GMT
-----Message d'origine-----
>De : Jim Jagielski [mailto:jim@jaguNET.com] 
>Envoyé : lundi 10 septembre 2007 14:00
>À : dev@httpd.apache.org
>Objet : Re: [PATCH] Apache 2.2.x: Implicit creation of new proxy_workers
>
>
>On Sep 10, 2007, at 6:01 AM, Plüm, Rüdiger, VF-Group wrote:
>
>>
>> Also the scoreboard is a limiting factor for this. The number of 
>> available scoreboard entries is determined during the configuration 
>> phase of the startup (it cannot even be changed during graceful 
>> starts, this is why we add some additional entries to the number of 
>> workers we have counted in the configuration).
>>
>> To be honest I am still not convinced that the dynamic creation of 
>> workers is a good idea at all.
>>
>
>I agree...


Thanks for your feedback. The issues mentioned in this thread are exactly what I was a little
worried about. However:

1. I do not really see how that could be used in a DOS attack as long as the client cannot
specify the address of the backend connection ( e.g. a rewrite rule that retrieves the backend
address in some query parameter, but that would represent a security issue under any circumstances
).

2. For all practical purposes the number of backends is rather limited ( a dozen ), at least
in the configurations that we use.

3. Comparative load tests we have made with and without persistent client connections show
that there is a significant performance gain when using persistent connections, both in terms
of response times and in terms of reduced load on the backend servers. There is no reason
to believe that a similar gain in performance cannot be achieved also with persistent backend
connections.


The problems you mention can be limited or eliminated by putting a configurable limit on the
number of proxy workers created dynamically, the default being 0 (none). One could even imagine
adding an equivalent number of slots to the scoreboard.

I therefore suggest supplementing the previously described mechanism with an additional configuration
directive, e.g. ProxyAddtlWorkersMax, default 0, with which one can specify the maximum number
of implicitly created workers. An equivalent number of additional scoreboard entries will
be allocated during the configuration phase.

I hope this is enough to address your concerns.

BR
-ascs


Mime
View raw message