httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: Proxy regressions
Date Wed, 10 Nov 2010 14:33:15 GMT
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
--


Mime
View raw message