httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: Talking about proxy workers
Date Fri, 06 Aug 2010 19:41:51 GMT
On 06.08.2010 13:13, Jeff Trawick wrote:
> nits:
> +      There are two builtin workers, the default forward proxy worker and the
> "built-in"


> +      optionally included in a<directive module="mod_proxy">Proxy</directive>
> +      directive.
> How about using "container" at the end instead of "directive"? (shrug)

Hah! I was actually thinking about that, but thought I had used 
"contained" instead of "included". But I wasn't, so changed to "container".

> +      ................. Direct workers can use connection pooling,
> +      HTTP Keep-Alive and individual configurations for example
> +      for timeouts.
> (dumb question: what's the diff between keepalive and connection
> pooling?  reuse for one client vs. reuse for any client?)

Good point. I think we do not have a concept of reuse for the same 
client. Connections are always returned to the pool after each 
request/response cycle. Even if a connection doesn't use keepalive, it 
can be pooled. I think the object in the pool is a bit more than just 
the TCP connection, but I didn't really investigate. There's room for 
improvement here but I was to lame to think more about it right now.

> That last part sounds a little awkward.  Maybe something like this:
> A number of processing options can be specified for direct workers,
> including connection pooling, HTTP Keep-Alive, and I/O timeout values.


> +      ........ Which options are available is depending on the
> +      protocol used by the worker (and given in the origin server URL).
> +      Available protocols include<code>ajp</code>,<code>fcgi</code>,
> +<code>ftp</code>,<code>http</code>  and<code>scgi</code>.</p>
> +
> The set of options available for the worker depends on the protocol,
> which is specified in
> the origin server URL.  Available protocols include ....


> +<p>A balancer worker is created, if its worker URL uses
> no comma


> +<p>Worker sharing happens, if the worker URLs overlap. More precisely
> +      if the URL of some worker is a leading substring of the URL of another
> +      worker defined later in the configuration file.
> <p>Worker sharing happens if the worker URLs overlap, which occurs when
> the URL of some worker is a leading substring of the URL of another
> worker defined later in the configuration file.


> +      In this case the later worker isn't actually created. Instead
> the previous
> +      worker is used. The benefit is, that there is only one connection pool,
> +      so connections are more often reused. Unfortunately all the
> configuration attributes
> +      given explicitly for the later worker overwrite the respective
> configuration
> +      of the previous worker!</p>
> This sounds like a discussion of pros and cons.  There's no pro, since
> the user didn't intend to configure it this way, right?

Technically there is a small pro, namely the origin server is confronted 
with less connections. I don't know enough about the implementation 
history (and didn't try to reconstruct it) to decide, whether this was 
done deliberately or it is just a consequence of the straightforward 
implementation. I do expect that the side effects of how it works now 
are highly unexpected, especially as users of mod_proxy start to 
configure worker more often with explicit configuration options (pool 
config, timeouts). I do plan to propose a slight change, namely not 
copying over default values to the alrady configured worker before 
applying the attributes of the second configuration to it.

I'd say the underlying problem is, that workers are identified by the 
URL. It would be cleaner if workers had a name. IMHO we have to live 
with the existing concepts and side effects for 2.4.

Thanks for your constructive comments. I'll work through the other 
replies, add some examples and repost another version.



View raw message