On Sat, 2008-09-13 at 14:55 -0400, Albert wrote:
> Couple of weeks ago I noticed that pound was not reusing open/existing 
> connections to the backend, even when backend is supporting HTTP/1.1 and 
> has content length.  To be precise, this happens when a service has 
> multiple backends, with no session-tracking enable.  This means that if 
> a client is making a request for a page, and then make subsequent 
> requests for images/javascript/css etc (on existing connection to 
> pound), pound will not always use the open connection to backend.  
> Here's how the requests are currently handled (assume 2 backends):
> 
> request#1 -> pound (randomly select a backend & connect to it) -> 
> backend#1.  Send response back -- but don't close either the client or 
> backend if both support HTTP/1.1 and have Content-Length.
> request#2 -> pound.  Pound will randomly select a backend.  If its 
> backend#1, it will reuse the open connection, from first request.  If 
> not, it will close connection to backend#1, and open a new connection to 
> backend#2. Send request to backend#2, receive response & send it back.
> request#3 > same path as request#2
> 
> 
> You can see, pound, with the client connection which is asking for all 
> of the content, will randomly look for a backend, and close the existing 
> backend connection, if a backend has changed, and open a connection to a 
> new backend.
> 
> I was a bit surprised by this behavior, and was wondering if pound 
> should be changed to try to reuse the backend connection (assuming 
> backend is still alive) before trying to find a new backend.  I 
> understand that I can change the behavior by introducing 
> Session-tracking (say by IP address), which would force pound to reuse 
> the backend. But I would think that pound will run faster if it didn't 
> have to close and then open new connections to backend when 
> Session-tracking is not used.
> 
> Any thoughts?

We'll look at the possibility of optimising this for randomly assigned
back-ends. In the meantime (for all list members): how many people could
benefit from it?
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904


--
To unsubscribe send an email with subject unsubscribe to [EMAIL PROTECTED]
Please contact [EMAIL PROTECTED] for questions.

Reply via email to