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

\
 
 \ /
  Last update: 2005-03-22 13:43    [from the cache]
©2003-2011 Jasper Spaans