You'll note that I ignored writes completely. Taking writes in account
makes the numbers worse (because you won't be able to use 100% of seek
time for reads).
> > 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.
That's right, which why you have an average 5 second long
conection. Most connections @ 600ms, some going to 80 mins. Average
length: 5 seconds.
It doesn't actually matter what the shape of the distribution is, only
what the average is. (sorry, I thought I had made it clear that that 5
seconds was the average connection lifetime).
> 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.
Not arguing with that at all. I was just pointing out that with
squid1.1 running a large cache there's not point in bashing the kernel
because the disks simply can't keep up anyway. I.e. you max out the
disks long before you come close to maxing out CPU or file
descriptors.
Michael.
-
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