Hi,

I wanted to follow up on this issue as I have some additional questions.

I built a new SuSE Enterprise 9 server on physical hardware (dual 1.2ghz 
procs, 3GB memory, RAID5) and found that the slow responsiveness
of pound persisted.

Just now I had the brilliant idea of modifying the pound.cfg by commenting 
out the "Session" section of ListenHTTP:

User "pound"
Group "pound"
Daemon 1
LogLevel 2  (turned up for debugging)
Alive 30

ListenHTTP
        Address 192.168.5.101
        port 80
        Client 10
        Change30x 1

        Service
                URL ".*"
        HeadRequire "Host:.*camproxy01.camsys.com.*"
                BackEnd
                        Address 192.152.136.3
                        Port 80
                End
#               Session
#                       Type IP
#                       TTL 300
#               End
        End
End

After doing this, pound responds like I would expect it to - fast and as 
if I were accessing the backend server directly.

My question now is, why would the above Session parameters cause this slow 
behavior?  Can someone explain exactly what the Session parameters do and 
when and how they should be used?  I am including it only because it 
seemed from the man pages that that is what I should do.

Much thanks as always,

--jeff

Jeffrey Brown/camsys wrote on 02/17/2006 10:29:26 AM:
[...]
pound?[...]

On Wed, 2006-02-22 at 10:18 -0500, Jeffrey Brown wrote:[...]

If you have a single back-end there is no reason to use any session
mechanism. The only reason for sessions is if you use multiple back-ends
that know nothing about each other - in that case each back-end may
create its own sessions, and thus the same client should always talk to
the same back-end.

The same applies to your URL definition (it is the default anyway) and
the HeadRequire (unless you want to do extra filtering).

BTW - you should probably upgrade to 2.0.2, though that should have no
effect in your case.

The big mystery is why should a session definition cause this sort of
delays - IP sessions are simply hashed, so there is no address
resolution or memory allocation involved. Could anybody else confirm
that the problem exists, or conversely that it works OK for them?

Finally it would be interesting to have a look at the log files: do you
see any unusual messages there (a dead back-end or a failed connection
perhaps)?[...]

> On Wed, 2006-02-22 at 10:18 -0500, Jeffrey Brown wrote:[...][...]

Couldn't it be somehow related to name resolution? Not that I understand
why it should, but it sounds like DNS lookups might happen here and cause
the delays mentioned. Just an idea how it feels...

Simon
[...]

On Wed, 2006-02-22 at 20:03 +0100, Simon Matter wrote:[...]

That is not the case - the session code does not do any additional
look-ups.[...]

I have same problem of delay in the test web server using pound,
I'm using one pc under linux and install the pound
and the backend using one pc with 2 vmware (assume as 3 web server)
if I try to directly open the web server, there is no delay appear
but when using pound, I notice some delay
and when I check out into the netstat of the pound server, when a user
open a web page it will make several connection to the same backend
server
example : user open the index.asp (which had 3 frames), the pound
server make a several connection to backend server
Is it how the pound works?
I wonder if the client more than 100 user, the connection to the
backend server will crowded (from multiple connection that pound
create)
Please correct me, If i'm wrong


On 2/23/06, Robert Segall <roseg(at)apsis.ch> wrote:[...]

On Sun, 2006-02-26 at 20:15 +0700, Agustinus Mulyawan wrote:[...]

Pound opens the same number of connections to the back-end(s) as the
client opened to Pound (each incoming connection has a corresponding
outgoing one). Most modern browsers open several connections per page,
even without frames - images and other objects are typical examples.

You may well have a heavily loaded network to the back-end(s) if it is
significantly slower than the incoming one (or if you use a single
network card for both).[...]