The box has 4GB of memory. Pound is using about 100MB. It has 2 Xeon 3.GHz processors. CPU utilization is between 3-10 percent for pound-- same as normal conditions, so CPU is not being used too much. The machine doesn't do anything else, so the rest of CPU is idle.

The machine has 1Gbt card, but is set to 100 Mbt Full-Duplex. I'm not sure how to check the packets/sec.

Anyway, I just looked at the archive, and found an email thread talking about this problem exactly "blocked requests with increased concurrency" on 4/29/07 from Khaled Hassounah. I don't think I have any other choice but to upgrade Linux version. We'll try RedHat Linux ES 5, which is running kernel 2.6.18, and hope it fixes the thread management problem.

Dave Steinberg wrote:

<snip>

taking 8-10 seconds. I understand that our network might be saturated, but I don't understand why pound is being bottlenecked within code where no network operations are being performed. This sounds like a thread-management problem in the kernel. Has anybody heard of this type of problem?

Under normal conditions (with 100 concurrent requests), the same "for" loop takes under 0.100 milliseconds -- 30,000 times faster. Is there anything I should check?

<snip>

I'd tend to agree with your gut feel. Something outside of pound is changing the time it takes for pound to do the same job! What does 'top' report when you're at peak usage? I'm mostly curious if your CPU is spending all its time processing interrupts instead of user code.

Any idea how many packets/second you're moving? Also - what are the CPU / NIC / bus specs on this machine?