On 10 Nov 2010, at 3:54 PM, Plüm, Rüdiger, VF-Group wrote:
As said this sounds doable for http backends, but not for https
backends
where we need to keep some data regarding the SSL state in the conn
rec
of the backend connection.
This is entirely fine, it's only the contents of the buckets in the
brigade that need to have a lifetime as long as the request, other SSL
specific data can work as it does now, there is no need for it to be
changed.
A further issue is with backend servers where keepalive is switched
off. Instead of acknowledging the connection close and releasing the
connection, we hold the connection open for ages until the client
finally acknowledges the request as finished.
Is this a problem of a too long lingering close period on the
backend server
blocking the expensive backend server threads?
I mean in general the backend server is the one who closes the
connection
if its keepalive timeout was used up and hence it can close the socket
from its side. The only thing that comes to mind that could keep it
blocked is a lingering close. Is this the case here?
We do see this, yes, and it caused two outages in our testing
environment recently caused by the initial version of the patch and
the original pool lifetime bug.
In v2.0, it was only saved in the connection if a keepalive was
present. If there was no keepalive, it was released immediately.
Which resulted in no connection pooling at all.
Having a connection pool isn't a win if it comes at the cost of
performance drag elsewhere. Ultimately the connections themselves in
our case are far cheaper than the application servers behind them.
Regards,
Graham
--
