httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryujiro Shibuya" <rshibuya0...@gmail.com>
Subject RE: Talking about proxy workers
Date Wed, 11 Aug 2010 09:24:40 GMT
> -----Original Message-----
> From: Paul Fee [mailto:pfee@talk21.com]
> Sent: Tuesday, August 10, 2010 9:18 PM
> To: dev@httpd.apache.org
> Subject: Re: Talking about proxy workers
> 
> Paul Fee wrote:
> 
> > Rainer Jung wrote:
> >
> >> Minor additions inside.
> >>
> >> On 06.08.2010 14:49, "Plüm, Rüdiger, VF-Group" wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Paul Fee
> >>>> Sent: Freitag, 6. August 2010 14:44
> >>>> To: dev@httpd.apache.org
> >>>> Subject: Re: Talking about proxy workers
> >>>
> >>>>
> >>>> Also, is it possible to setup these three reuse styles for a
> >>>> forward proxy?
> >>>>
> >>>> 1: No reuse, close the connection after this request.
> >>>
> >>> Yes, this the default.
> >>>
> >>>> 2: Reuse connection, but only for the client that caused its creation.
> >>>
> >>> No.
> >>
> >> Even if you configure pooled connections like in the example given in
> 3,
> >> the connections are returned to the pool after each request/response
> >> cycle. They are not directly associated with the client connection.
> >>
> >> But: if the MPM is prefork, the client connection is handled by a single
> >> process which doesn't handle any other requests during the life of the
> >> client connection. Since pools are process local, in this case the pool
> >> will always return the same connection (the only connection in the
> >> pool). Note that this pooled connection will not be closed when the
> >> client connection is closed. It can live longer or shorter than the
> >> client connection and you can't tie their lifetime together.
> >>
> >> Whether the proxy operates in forward or reverse mode doesn't matter,
> it
> >> only matters how the pool aka worker is configured. See 3.
> >>
> >>>> 3: Pool connection for reuse by any client.
> >>>
> >>> Yes, but this is needed separately for every origin server you forward
> >>> to:
> >>>
> >>> <Proxy http://www.frequentlyused.com/>
> >>>     # Set an arbitrary parameter to trigger the creation of a worker
> >>>     ProxySet keepalive=on
> >>> </Proxy>
> >>
> >> Pools are associated with workers, and workers are identified by origin
> >> URL. In case of a reverse proxy you often only have a few origin
> >> servers, so pooling works fine. In case of a forward proxy you often
> >> have an enormous amount of origin servers, each only visited every now
> >> and then. So using persistent connections is less effective. It would
> >> only make some sense, if we could optionally tie together client
> >> connections and origin server connections.
> >>
> >> Regards,
> >>
> >> Rainer
> >
> > I'm using the worker MPM, so connection sharing between clients can
> > happen.
> >
> > As you've pointed out, pooling works well for reverse proxies as there
> are
> > few backends and the hit rate is high.  For forward proxies, there are
> > numerous destinations and the pool hit rate will be low.  The pool has
> a
> > cost due to multi-threaded access to a single data structure, I presume
> > locks protect the connection pool.  Locks can limit scalability.
> >
> > I'm wondering if pools should be restricted to the reverse proxy case.
> > Forward proxies would couple the proxy->origin server connection to the
> > client side connection.  Since connections can not be shared, there's
> no
> > need for locking.  We'd loss the opportunity to share, but since the
> > probability of a pool hit by another client is low, that loss should be
> > acceptable.
> >
> > Essentially, I'm asking if it would make sense to implement "2: Reuse
> > connection, but only for the client that caused its creation".  This could
> > be a configurable proxy worker setting.
> >
> > Thanks,
> > Paul
> 
> Here's a suggestion to refine connection pooling for forward proxies.
> 
> Can a connection to an origin server be tightly coupled to the client
> connection for the lifetime of the client connection?  Then, when the client
> connection closes, the origin server connection can be placed in the pool
> for possible reuse by another incoming client connection.
> 
> This would allow a client to reuse its own origin server connection without
> having to do a lookup in the pool.  We'd save on lookup costs and pool
> locking.  However connections would still go into the pool after the client
> has finished with it, for the potential benefit of other clients.
> 
> When a client makes a request, mod_proxy looks to see if there's an existing
> origin server connection coupled to the request_rec.  If there's no
> connection or the connection is not to the correct origin server, then
> perform a pool lookup.  If that fails, then create a fresh connection.
> 
> Does this should feasible?  Can we do this with mod_proxy already?  Is it
> worth implementing?
> 
> Thanks,
> Paul

Current implementation seems to close the origin server connection every time 
even if the client connection is kept opened for the next client request 
(which is highly possibly for the same origin server).

I agree with Paul's idea, which seems a good way to enable both of ...
  (1) keeping origin server connection opened for exclusive use of a client,
  (2) connection pooling after use.
In the forward proxy, in my opinion, the advantage of (1) cannot be ignored, 
even though some might think the advantage of (2) may be limited than that in 
the reverse proxy.

Regards,
Ryujiro Shibuya


Mime
View raw message