On 10/19/2008 07:35 PM, Jim Jagielski wrote: > > On Oct 18, 2008, at 4:22 PM, Graham Leggett wrote: > >> Ruediger Pluem wrote: >> >>>> As a result, the connection pool has made the server slower, not >>>> faster, >>>> and very much needs to be fixed. >>> I agree in theory. But I don't think so in practice. >> >> Unfortunately I know so in practice. In this example we are seeing >> single connections being held open for 30 second or more. :( >> >>> 1. 2.0.x behaviour: If you did use keepalive connections to the backend >>> the connection to the backenend was kept alive and as it was bound >>> to the >>> frontend connection in 2.0.x it couldn't be used by other connections. >>> Depending on the backend server it wasted the same number of resources >>> as without the optimization (backend like httpd worker, httpd >>> prefork) or >>> a small amount of resources (backend like httpd event with HTTP or >>> a recent >>> Tomcat web connector). So you didn't benefit very well from this >>> optimization >>> in 2.0.x as long as you did not turn off the keepalives to the >>> backend. >> >> Those who did need the optimisation, would have turned off keepalives >> to the backend. >> >>> > > Trying to grok things better, but doesn't this imply that > for those who needed the optimization, disabling the > connection pool would be the required work-around for 2.2?
No. Without a connection pool (e.g. the default reverse worker) the backend connection does not get freed any faster than without a connection pool. Ok strictly spoken you cannot turn off the connection pools at all (reverse is also one), you can only turn off a reuse of the connections. Regards Rüdiger
