On Fri, 10 Jul 1998 09:32:25 +0800, "Michael O'Reilly"
<michael@metal.iinet.net.au> said:
> Yes, I saw the paper. However, the issue here is the average
> connection length vs the maximum number of disk I/Os per second
> possible.
That's only one of the issues, I think.
> For single process (i.e. can only have one request in the disk queue
> at a time), on 10ms disks (say), and a HUGE ram cache (~ 1.5% of disk
> space), you'd be able to cache all the metadata, so you're on a single
> seek to read/write data (say). This gives you a maximum connection
> rate of
> max_rate == disk_IOs_per_second * 1.5
> as around 66% of all requests will require disk access.
This is very simplistic. For a start, a lot of the requests which
require disk access will be doing disk writes, not reads, so the extra
concurrency can be obtained in the kernel using write-behind caching.
> So for 5 second connection length (that's worse than measured in
> australia on terrible links with 500ms RTTs),
It's not the typical service time which kills you: it's the connections
which, due to any number of possible reasons, take unusually long to
complete which fill the queue.
I'm not disputing the need for threaded disk IO in the proxy. The fact
is, however, that improving select() and get_fd() performance in the
kernel, these folk measured a real-life throughput improvement of up to
58% on their instrumented servers.
In short, just because some services create an artificial internal
bottleneck by single-threading their disk IO, doesn't get away from the
fact that kernel select() performance simply doesn't scale right now.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html