The performance win for HTTP/1.1 Keep-Alive, unfortunately, is not
clear cut. It was designed to improve performance from the client's
perspective when the network (and not the server) is the performance
bottleneck. If requests are pipelined, there is no negative impact on
server performance, but when there are non-zero idle times on
connections there is mounting evidence that 1.1 Keep-alive _degrades_
the saturation point of servers. (The exact cause is still being
studied; it is unclear whether this degradation is governed by OS
overhead, server architecture, etc.)
> > Possibly. But according to Squid's own doc, the primary problems
> > in Squid performance are
> >
> > 1) Not enough memory
> > 2) Too slow disks
>
> I think this is for squid-1.1. squid-1.2 is a bit different and probably
> would benefit from sendfile. It already supports async io (via threads).
Hmm... squid's monolithic, single-thread architecture is (arguably)
its biggest performance feature. I'm wondering how the use of threads
for AIO will play out, performance-wise...
> > There are so many other likely bottlenecks, like disk bandwidth (sendfile
> > doesn't help here as far as I can see)
>
> I keep hearing disk bandwidth is an issue, but I've yet to see it. Disk seek
> times are a problem, but disk IO usually isn't.
Perhaps "filesystem latency" would more accurately describe the
bottleneck?
Adam
-- You crucify all honesty \\Adam D. Bradley artdodge@cs.bu.edu No signs you see do you believe \\Boston University Computer Science And all your words just twist and turn\\ Grad Student and Linux Hacker Reviving just to crash and burn \\ <>< ---------> Why can't you listen as love screams everywhere? <--------
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu