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?

I've already reported this a year ago or so. The developers are prefeclty
fine with the idea, that the system will run out of source ports, and the
whole loadbalancing system becomes unavailable after such a high traffic.
They suggest to use workarounds, like inceasing the available source port
range, and having lower traffic. But any sane-minded person can see, that
these resources are quite limited, and these are not a solutions at all,
just worthless workarounds.

On Sat, 13 Sep 2008 14:55:41 -0400
Albert <pound(at)alacra.com> wrote:
[...]

[...]

On Sat, 2008-09-13 at 14:55 -0400, Albert wrote:[...]

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?[...]

> We'll look at the possibility of optimising this for randomly
assigned[...]

Theoretically I would, since I use multiple backends w/o session 
tracking.  In reality I'm probably not at the traffic level where it 
would matter.

I'm not sure I love this idea, since the point of not using sticky 
sessions is that there's no affinity for a particular backend.  Perhaps 
it could be optional?  "AlwaysReuseConnections" or something?

Regards,[...]

I'm not familiar enough w/ the code, but why is it that it only affects
people that aren't using session tracking?  I currently use the IP based
session tracking.  

How can you find out what you current connection limit is with one's
particular installation of pound?  Is there any good benchmarking
software that anyone could recommend?

I haven't run into this problem (yet), but I'd rather avoid if it I can.

--Alfonso 

-----Original Message-----
From: Robert Segall [mailto:roseg(at)apsis.ch] 
Sent: Monday, September 22, 2008 11:38 AM
To: pound(at)apsis.ch
Subject: Re: [Pound Mailing List] reusing connections to backends

On Sat, 2008-09-13 at 14:55 -0400, Albert wrote:[...]
[...]
backend.[...]
[...]
back.[...]
[...]
[...]
[...]

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 pound(at)apsis.ch.
Please contact roseg(at)apsis.ch for questions.
[...]

Dave Steinberg wrote:[...][...]
I don't mind this being optional, but I wonder why wouldn't you want to 
reuse the connection to the backend?  Pound will automatically close the 
connection to the backend if backend is HTTP/1.0 or "Connection: close" 
is issued, forcing a new connection to backend for new requests.

The case I was describing had backend being HTTP/1.1 and "Connection: 
Keep-Alive" issued by backend.  In such case, I would think you'd want 
pound to reuse the connections.  Otherwise, whats the point of having 
"Connection: Keep-Alives" on your backend with pound as your proxy?

To us this is not a very big deal, as I changed our configuration to use 
IP address for session-binding.  But this takes away a randomized 
distribution to the backends, in such case.  I would think the 2 
settings should not be inter-dependent.

On Mon, 2008-09-22 at 12:54 -0400, Alfonso Espitia wrote:[...]

Actually this would affect only people who do NOT use session tracking.
For those who do the back-end would be fixed after the first request.

The scenario Albert was alluding to is one where you have several
possible back-ends, with no session tracking: in this case it may happen
that the back-end supports HTTP/1.1 (thus allowing connection reuse),
but Pound chooses at random another back-end.

The problem with sticking with the connection is that the load balancing
is less than optimal, at least in the short term. I suspect over longer
periods this would even out - YMMV.[...]

> The case I was describing had backend being HTTP/1.1 and "Connection:
[...]

You raise a good point here, definitely.
[...]

At least from where I stand right now, I like the fact that requests are 
spread even across my backends.  I find this is extremely helpful in 
debugging, since if one backend gets out of sync with the others, its 
just a matter of hitting refresh to expose it.

So I agree with you that this is a desirable feature, but for me the 
performance increase wouldn't be so great that I'd be willing to give up 
the ease for finding problems.  I can definitely see where if my traffic 
grew, I might want this.

Regards,[...]

Thank you for the explanation, that makes sense.

To the other part of the question.  Does anyone know a good benchmark,
or how to test the theoretical limit of one's pound installation.  I
would suspect it depends a lot on the hardware it's installed on, but
from reading various posts, it sounds like it has a lot to do with your
distribution's kernel parameters as well.

So, is there a good way to test how many concurrent connection you can
handle?

Thanks.

--Alfonso

-----Original Message-----
From: Robert Segall [mailto:roseg(at)apsis.ch] 
Sent: Tuesday, September 23, 2008 12:39 PM
To: pound(at)apsis.ch
Subject: RE: [Pound Mailing List] reusing connections to backends

On Mon, 2008-09-22 at 12:54 -0400, Alfonso Espitia wrote:[...]
can.

Actually this would affect only people who do NOT use session tracking.
For those who do the back-end would be fixed after the first request.

The scenario Albert was alluding to is one where you have several
possible back-ends, with no session tracking: in this case it may happen
that the back-end supports HTTP/1.1 (thus allowing connection reuse),
but Pound chooses at random another back-end.

The problem with sticking with the connection is that the load balancing
is less than optimal, at least in the short term. I suspect over longer
periods this would even out - YMMV.
--
?Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904


--
To unsubscribe send an email with subject unsubscribe to pound(at)apsis.ch.
Please contact roseg(at)apsis.ch for questions.
[...]