Messages in this thread | | | Date | Tue, 19 Oct 1999 14:24:18 -0400 (EDT) | From | Chuck Lever <> | Subject | Re: nonblocking disk read again |
| |
On Mon, 18 Oct 1999, Stephen C. Tweedie wrote: > > Yes, and in principle it would be possible to make the sendfile > > completely asynchronous, essentially by doing the disk IO asynchronously > > from a dedicated kernel thread. > > > The other way of doing this is with callbacks; simply register the async > > sendfile function with an IO completion hook, and keep all of the state > > for the async sendmail in a structure. Then you can handle the async > > sendmail processing in a bottom half task, without having to dedicate a > > whole kernel thread to it. > > You can't pull stuff from disk in a bottom-half. You _can_ reserve a > small number of kernel threads to deal with the async callbacks, though, > and keep the disk-to-network pipelines busy.
i've just come across an interesting study on network connection scheduling that may be relevant here. see:
http://www.cs.bu.edu/techreports/99-003-connection-scheduling-in-web-servers.ps.Z
essentially they show that carefully scheduling the transmission of network packets has positive effects on latency (client-perceived server responsiveness), and few bad effects on bandwidth (how long it takes to deliver a large file). their simple scheduler chooses the connection with the shortest bytes remaining to transmit.
an async sendfile() implementation would be an ideal place to try this.
-- snip here --
Connection Scheduling in Web Servers Mark E. Crovella, Robert Frangioso, Mor Harchol-Balter
Abstract
Under high loads, a Web server may be servicing many hundreds of connections concurrently. In traditional Web servers, the question of the order in which concurrent connections are serviced has been left to the operating system. In this paper we ask whether servers might provide better service by using non-traditional service ordering. In particular, for the case when a Web server is serving static files, we examine the costs and benefits of a policy that gives preferential service to short connections. We start by assessing the scheduling behavior of a commonly used server (Apache running on Linux) with respect to connection size and show that it does not appear to provide preferential service to short connections. We then examine the potential performance improvements of a policy that does favor short connections (shortest-connection-first). We show that mean response time can be improved by factors of four or five under shortest-connection-first, as compared to an (Apache-like) size-independent policy. Finally we assess the costs of shortest-connection-first scheduling in terms of unfairness (i.e. the degree to which long connections suffer). We show that under shortest-connection-first scheduling, long connections pay very little penalty. This surprising result can be understood as a consequence of heavy-tailed Web server workloads, in which most connections are small, but most server load is due to the few large connections. We support this explanation using analysis.
- Chuck Lever -- corporate: <chuckl@netscape.com> personal: <chucklever@netscape.net> or <cel@monkey.org>
The Linux Scalability project: http://www.citi.umich.edu/projects/linux-scalability/
- 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.tux.org/lkml/
| |