Whenever the WebDAV repository will be accessed over the Internet or by a large number of users, performance considerations are important. Many tricks that improve performance also improve scalability and vice versa, so don't ignore one if the other is important. Improving server performance is an art, but it's an art that depends more on programming choices (language, thread and memory management, and data lookup and caching) than on protocol usage choices. In other words, designing a high-performance WebDAV server is a lot like designing any other Internet server. Besides, not many implementors will write their own WebDAV server from scratch. So I'll ignore the server implementation performance considerations and refer readers to language-specific resources like [Bulka00]. The usual WebDAV performance problem isn't slow servers, it's inefficient clients. Clients that make more requests and more roundtrips than are needed not only slow their own performance, but they also make demands of the server that may affect other clients and the server's performance overall. There's very little the WebDAV server implementor or administrator can do about a client that makes more requests than it needs to. WebDAV was designed to minimize roundtrips because the latency of an HTTP request across the open Internet is high enough to get quite painful if repeated. Early Web browser designers discovered this once Web page authors started putting a dozen small images (icons, bullets, logos) in a Web page [Padmanabhan95]. If the Web browser downloads the HTML document, then makes a request for the first image and waits for a response before asking for the second image, the document takes at least 2 x (n + 1) x L seconds to load, where n is the number of images and L is the latency, or number of seconds it takes for a short message to arrive at its destination. Some HTTP mechanisms were designed to alleviate the latency cost. 15.2.1 Minimizing Unnecessary RequestsThere are a number of ways to reduce roundtrips, and one of them is simply to think carefully whether each request is really required, or whether multiple requests can be combined.
15.2.2 Keeping Connections AliveRecall that TCP also adds roundtrips to interactions whenever the TCP connection is terminated and needs to be restarted. HTTP has developed two tools to minimize TCP connection restart costs:
15.2.3 Multiple ConnectionsSome clients initiate many parallel HTTP requests using multiple TCP connections. This is often done to download all the images in a Web page. As soon as the image names are known, the client requests each of them, each in its own connection. This generally improves perceived performance for the user. TCP connection startup costs are unavoidable when the client chooses to do this. An extra roundtrip is required to set up the connection. TCP slow start [Stevens98] makes the new connection less efficient at first. Transport layer security (SSL or TLS) makes the situation only slightly worse because these protocols offer a connection resumption feature once initial shared secrets have been established. The place where SSL/TLS demands an unavoidably high cost is in setting up the very first connection and its security context, but users are accustomed to a startup cost the very first time they connect to a server. Because multiple connections are definitely higher load for the server, a considerate client implementation would only use multiple connections if the benefits outweigh the cost. For example, the client might initiate separate connections only for downloading or uploading large resources and use the original connection for all requests that are likely to be quick. 15.2.4 Minimizing Server LoadAnother consideration, which sometimes conflicts with the goal of reducing roundtrips, is that many operations have a high server load. Some of these have been discussed on the WebDAV mailing list:
A general recommendation is to use Depth: infinity PROPFIND requests only when they are a clear communications improvement, not just a programming shortcut. If roundtrip reduction is the reason that the client is doing a Depth: infinity request, even though not all the information returned is being used, consider doing pipelined requests for the information that will be used. An even stronger recommendation can be made in the case of allprop: Don't use it. WebDAV servers may have resources with many properties, even hundreds of properties. Even if a client retrieved the values for all properties on a resource, what would it do with the ones it was unfamiliar with? Thus:
|