Re: httpd 2.3.7 as beta?

2010-08-11 Thread Paul Querna
On Tue, Aug 10, 2010 at 1:01 PM, Jim Jagielski j...@jagunet.com wrote:
 Subject for discussion...  Does truck look good enough
 for Beta?

 In either case, as alpha or beta, I plan to RM this next week.

It has been stable on www.apache.org once we turned off sendfile.
There was some discussion about chaging that by default, but I don't
think that blocks it for beta.

I think it might be worth seeing if there are any things we want to
remove too, but as long as we have a couple betas, it doesn't need to
happen before the first, just before GA.

Anyways, +1, do it :)

Thanks,
Paul


RE: Talking about proxy workers

2010-08-11 Thread Ryujiro Shibuya
 -Original Message-
 From: Paul Fee [mailto:p...@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 

Re: httpd 2.3.7 as beta?

2010-08-11 Thread Jim Jagielski

On Aug 11, 2010, at 4:09 AM, Paul Querna wrote:

 On Tue, Aug 10, 2010 at 1:01 PM, Jim Jagielski j...@jagunet.com wrote:
 Subject for discussion...  Does truck look good enough
 for Beta?
 
 In either case, as alpha or beta, I plan to RM this next week.
 
 It has been stable on www.apache.org once we turned off sendfile.
 There was some discussion about chaging that by default, but I don't
 think that blocks it for beta.
 

Agreed... I likely have some time though to
get that in before beta though...

 I think it might be worth seeing if there are any things we want to
 remove too, but as long as we have a couple betas, it doesn't need to
 happen before the first, just before GA.
 
 Anyways, +1, do it :)
 
 Thanks,
 Paul
 



Re: Talking about proxy workers

2010-08-11 Thread Jim Jagielski

On Aug 11, 2010, at 5:24 AM, Ryujiro Shibuya wrote:
 
 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.
 

It would be most ideal if we pulled our forward and reverse
proxies as sep modules instead of a single one, but that's
an exercise for post 2.4 I think...



Re: httpd 2.3.7 as beta?

2010-08-11 Thread Philip M. Gollucci
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/11/10 12:55, Jim Jagielski wrote:
 
 On Aug 10, 2010, at 10:22 PM, Philip M. Gollucci wrote:
 
 On 8/10/2010 4:01 PM, Jim Jagielski wrote:
 Subject for discussion...  Does truck look good enough
 for Beta?

 In either case, as alpha or beta, I plan to RM this next week.
 Which apr are we 'bundling' these days with trunk?

 
 apr-1.4
 apr-util-1.3
I recall(pquerna) using a -dev tag before.  Are the official latest
releases sufficient ?




- -- 
- 
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70  3F8C 75B8 8FFB DB9B 8C1C
Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354
VP Apache Infrastructure; Member, Apache Software Foundation
Committer,FreeBSD Foundation
Consultant,   P6M7G8 Inc.
Sr. System Admin, Ridecharge Inc.

Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)

iD8DBQFMYrtFdbiP+9ubjBwRAvSmAJ9gtBarzxi6dlLEeKrsI7TNAA92mQCbBo+k
Tm+sVqGvIl1LPG37wku5xpU=
=8XhW
-END PGP SIGNATURE-


Re: httpd 2.3.7 as beta?

2010-08-11 Thread Jim Jagielski

On Aug 11, 2010, at 11:01 AM, Philip M. Gollucci wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 08/11/10 12:55, Jim Jagielski wrote:
 
 On Aug 10, 2010, at 10:22 PM, Philip M. Gollucci wrote:
 
 On 8/10/2010 4:01 PM, Jim Jagielski wrote:
 Subject for discussion...  Does truck look good enough
 for Beta?
 
 In either case, as alpha or beta, I plan to RM this next week.
 Which apr are we 'bundling' these days with trunk?
 
 
 apr-1.4
 apr-util-1.3
 I recall(pquerna) using a -dev tag before.  Are the official latest
 releases sufficient ?

That's what I've released with (latest releases) when I've done trunk 
tarballs...