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/