My problem seems related to:
http://www.apsis.ch/pound/pound_list/archive/2006/2006-11/1163201866000

At first I was using 2.1.6 from blastwave, so I downloaded and
compiled 2.2.4. I get the exact same results.

Solaris 10_U3, E280R with 4GB, dual 900MHz US-III. The backends are
the same hardware, running apache-2.2.4.

Pages with lots of content (images) load very slowly. Up to 15 seconds
at times. So I decided to test with an 800K image. Wget straight to a
backend takes < 1 sec, but through pound it's 9-15 seconds.
I checked, and the TCP_NODELAY flag is set in http.c, just like the
above posting implied. So I'm now failover-capable, but most of our
websites are dog-slow. (CMS sites.. mambo, etc, loading lots of
images).

During a wget (through pound) dtrace shows the following syscalls for
the pound process (but there's also other traffic):
CALL                                        COUNT
nanosleep                                       1
lwp_exit                                       14
lwp_sigmask                                    14
accept                                         15
connect                                        15
fstat                                          15
getpid                                         15
getsockopt                                     15
lwp_continue                                   15
lwp_create                                     15
lwp_kill                                       15
open                                           15
putmsg                                         15
schedctl                                       15
setcontext                                     15
so_socket                                      15
doorfs                                         30
shutdown                                       30
gtime                                          32
close                                          45
fcntl                                          45
setsockopt                                     90
read                                          123
write                                         200
pollsys                                       353

Hmm. Polling.

My config is pretty basic. I have a Service with 3 backends. I did
recently add some URL pattern matching, but the problem existed
before.

What else can I look at?

Thanks,
 -Charlie

On Feb 13, 2007, at 1:37 PM, Charlie Schluting wrote:
[...]

We've also been seeing similar page load times for image-heavy  
pages.  Suggestions would be very much appreciated.

Our current configuration:
Pound version: 2.1.6
Debian etch/testing
Kernel: 2.6.8-3-k7-smp
Session type is COOKIE
3 BackEnds (tomcat)

-Blake

Charlie,

I had posted the original problem with slow images, but even though 
problems sound similar, I don't think they are the same.  In our case, 
having a page with 200 images gave very slow times. I noticed a .2 
second delay on every image request process (times 200 gives you about 
40 seconds). A 0.2 second delay on a large file would not make a big 
difference.

I just ran a test on our systems to get an 8MB file.  It took less than 
a 1 second to get the file (on the same 1 Gigabit network) via pound and 
directly to the server.  We have 2 locations, so when I went to the 
other location, it took 8 seconds (in line with my expectation, as it 
did 1 Mb/s) via pound and directly with the backend webserver. 

Albert

Charlie Schluting wrote:[...]

On Feb 14, 2007, at 1:02 PM, Albert wrote:
[...]

I agree, it looks like a different issue.  The slow image loading  
problem is something that most people don't notice since they cache  
things after the first time, but it does seem to be very noticeable  
on first-time page loads.  Not may users report it because they  
assume it's just a momentary glitch with their own access speed, etc.

Another issue I have which may or may not be related is I see 500  
errors occasionally.  Usually when these problems occur I see  
something like:
Feb 14 06:27:24 lb001 pound: error copy server cont: Connection timed  
out
or
Feb 14 09:08:14 lb001 pound: unexpected chunked EOF: Connection timed  
out
in the logs.

I've tried increasing the BackEnd and Client timeouts without much  
effect.

-Blake

On Tue, 2007-02-13 at 13:37 -0800, Charlie Schluting wrote:[...]

I've seen some very slow response times when I try enabling RootJail in
my config.  I must not have all the files I need in the chroot directory
or something, and haven't bothered trying to figure out what I'm doing
wrong, so I just commented it out again and things went back to normal
(although slightly less secure).  I recently tried it again after
upgrading to 2.2 and saw the same behavior.  Dunno if it's causing your
problem, but maybe it's something to try.

Sean

On 2/14/07, Blake Barnett <shadoi(at)nanovoid.com> wrote:[...]

One suggestion was for me to try it on a Linux box, which support
epoll. The fact that you see the same thing on Linux is discouraging
:(

I'm not using a chroot jail, as one poster noted.
It's true that images cache in the local browser, but on one of our
pages we load a random 20K image each time, and that always loads
slow.

I was going to give an AMD64 Linux server a try, but perhaps my
efforts are better spent trying something else? I know that's a rude
question, but I don't mean it that way. Coincidentally I just recently
wrote an article about using pound (google 'pound proxy' = 4th hit),
and I claimed that it performs very well. Hopefully this is just a bug
that can be fixed.

 -Charlie

On Tue, 2007-02-13 at 13:37 -0800, Charlie Schluting wrote:[...]

There is nothing special in images - they are just regular content,
treated like any other. It is much more likely that you see delays in
address resolution (for the back-end for example). Using 2.2.4: did you
try to time several times the same request for a single image? If the
first is slow and the following ones are fast it definitely is a
resolution problem (2.2.4 caches the DNS results).

There is also nothing surprising about polling: Pound uses poll() to
wait for responses. If your back-end is slow then the poll() just waits
- that's normal behaviour.

Finally have you looked at the back-end logs? Do you see the image
requests, and if yes are they as long as you seem to think?[...]

On Feb 15, 2007, at 8:19 AM, Robert Segall wrote:
[...]

I don't know about Charlie, but in our case, the actual image loading  
(not a delay before it gets loaded) is what takes the longest.  For  
an image of 400K or so, you can actually watch the image draw as if  
it were on a 14.4k Modem.  Take pound out of the mix, and it's  
blazingly fast.
[...]

The only odd things I've seen in the logs are the timeouts I posted.

-Blake

On 2/15/07, Blake Barnett <shadoi(at)nanovoid.com> wrote:[...]
Precisely, I see the same. It's not "images" per se, it's just larger content
:)

 -Charlie

Further, I'm also getting tons of these errors:
[ID 702911 daemon.warning] backend 0.0.0.0:8 connect: Invalid argument

And stuff is failing randomly. I doubt that's related, but :(

Well you aren't going to believe this..

Things improved 100% when I realized that our 280R had a duplex mismatch!

The Sun eri driver has issues with speed/duplex negotiation if the
switch it's connected to disappears and comes back. The c3750 the
proxy server is connected to was rebooted right about the same day I
switched to pound.

Anyway, I thought you'd like to know that it's working well now.

I can fetch 500K images in ~0.02 secs now, through pound. I had
thought about checking for interface errors, but never actually had
the thought when I was at a terminal :)

 -Charlie