[lkml]   [1998]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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

    You crucify all honesty \\Adam D. Bradley
    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

     \ /
      Last update: 2005-03-22 13:43    [W:0.021 / U:11.900 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site