Messages in this thread | | | Date | Fri, 26 Jun 1998 13:17:42 -0400 (EDT) | From | "Adam D. Bradley" <> | Subject | Re: Thread implementations... |
| |
On Fri, 26 Jun 1998, Chris Wedgwood wrote: > On Thu, Jun 25, 1998 at 11:57:48AM +0200, Erik Corry wrote: > > > All these options aren't pretty. I would hope you could do > > without them. If sendfile blocks until it is complete, there > > seems little point in having a close-on-send, and if you look > > at Deans website, you can see that the question of closing a > > TCP/IP socket properly is non-trivial, and probably not for > > kernel-space-only. > > In the case of web servers and proxy caches, I don't think close on send is > worth while, because it defeats the purpose and the (possibly very great) > win experienced with HTTP/1.1.
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
| |