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?