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:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2008 12:39 PM
To: [email protected]
Subject: RE: [Pound Mailing List] reusing connections to backends

On Mon, 2008-09-22 at 12:54 -0400, Alfonso Espitia wrote:
> 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.

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 [EMAIL PROTECTED]
Please contact [EMAIL PROTECTED] for questions.

--
This message has been scanned for viruses and
dangerous content by SecureMail, and is
believed to be clean.



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

Reply via email to