httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 59319] ProxyPass connectiontimeout not honored with specific target url
Date Fri, 15 Apr 2016 09:58:22 GMT

--- Comment #3 from Rainer Jung <> ---
(In reply to Ben RUBSON from comment #2)

> Unfortunately as you said there is no possibility to enforce default values
> for the default worker.
> Once again some values would certainly not make sense for the default worker
> (connection pooling...), but some of them, such as for example
> connectiontimeout, timeout... would be worth it.

Yes and I think I have to fully very this (I checked the code but only reading
it) and if it is true, then being able to either define setting for the default
worker or being able to set default settings for all worker including the
default would be a useful enhacement, probably both of it. Your use case of
handling many backends and deciding between them based on
policy/convention/table is happening more and more out there.

> I could think about the following : each time a new host/port pair arrives
> on the server, automatically create its small configuration file containing
> only the following macro line :
> Use MyWorker hostX:portX
> And reload the Apache configuration.
> Macro would be defined in the main configuration.
> The main configuration would also contain something like :
> Include /path/to/workers/configurations/worker.*.conf

I know installations who do it exactly like that.

> That's another story but, declaring a worker for each host:port would
> activate connection pooling for each one of them.
> I think connection pooling would be work it in my use case : each time a
> user connects to the service, it is forwarded to the same reserve proxy. So
> connection pooling could be a good thing to have.

Yes, if there would be reuse, ie. often the next request for the same backend
hits before the connection runs into its HTTP keep-alive timeout (especially
the one set by the backend!).

> However, can connection pooling have an impact in terms of performance if
> Apache has to manage many workers ?

I expect no problem in case of say less than 100 workers. I don't remember
reports for any numbers, but if you have many more workers, than it might be,
that there's not so much relevant experience out there and some testing would
be recommended.

> Can we tend to somethig like denial of service if the maximum number of
> connection in pools is reached, and no other connections to other workers
> can be made ?
> Or is there no limit at all here ?

Pools are always local in Apache processes. Processes do not share connections
to backends between themselves. The limit (maximum number of connections per
backend) is equals to the number of threads in the process. Since Apache can't
handle more requests in one process at one point in time than it has threads,
and we allow the same number of backend connections, you should never run into
a connection limitation unless you reduce the limit by configuring a smaller
limit. Pooling here is more about reuse than limiting.

If you would use it to limit the access to the backend via a threshold, the
limit would be per process and you can't control which request ends up in which
process. So limiting access via the connection pool would not be very precise.
There's a "busy" counter which is shared between the Apache processes and knows
how many requests are in-flight on the backends (more precisely those that come
from this Apache) and one could limit using the busy counter to protect the
backend, but I think (not 100% sure) we don't yet spport limiting based on the
busy value. 

> Being able to define default worker (or clones of worker) parameters would
> also improve P flag of mod_rewrite.

Yup. Maybe we sould add another Bugzilla as a feature request for adding a way
to configure the default workers (forward, reverse) and to cinfigure defaults
for all workers. Both should be per VHost and values would be inherited from
global server to VHosts.

You are receiving this mail because:
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message