A couple questions and a couple observations: 1) How many network cards are in the server? (How many unique interrupt handlers for the network?)
2) How much context switching was going on, and how impacted were the mutexes (see mpstat)? 3) Was the workload uniformly distributed across the CPUs? I've seen large MP systems completely fail to distribute the workload, and suffer because of it. My current theory for why this occurs is that the interrupt load is overwhelming the CPU where that interrupt is being serviced. This combined with the relatively small amount of userspace work that must be done to push a small static file out is wreaking havoc on the scheduler (and it's probably more dramatic if your system enabled sendfile support). -aaron On Tuesday, February 11, 2003, at 09:34 AM, Min Xu wrote:
Thanks to Owen Garrett, who reminded me that I should have mentioned a little more details about the client configuration. My modified SURGE client fetch web pages on an "object" basis, each object contains multiple pages. For each object the client uses HTTP/1.1 keepalive, but not pipeline. After an object being fetched completely, the client close the connection to the server and reopen a new one for next object. The delay time I added was between each web pages, so the client goes to sleep for a little while with the connection being still open. FYI, I have attached the client code. Anyone have a wild guess on what's going on? ;-) Thanks a lot!
