18.6. Web Services Performance

The performance of a Web Service from both the client and server side is affected by a variety of factors. Some are .NET related and others are inherent in the technology. The solutions for improving Web Services performance range from shaving a few milliseconds off the way .NET sends a request to simply eschewing Web Services for an alternate protocol when transferring large amounts of data. We'll look at all of these.

Configuring the HTTP Connection

Connections (HTTP) to Internet resources are managed in .NET by the ServicePoint class. This class includes properties to specify a connection's timeout interval, set its security protocol, and manage the use of server security certificates. It also includes properties that directly affect how much delay is incurred before a Web Service request is transmitted over a network: UseNagleAlgorithm and Expect100Continue. Despite the awkward sounding names, setting their properties is as easy as assigning a TRue or false value to them. The default for both is true.

Expect100Continue

This property determines whether a POST request should expect to receive a 100-Continue response from the server to indicate that the data can be posted. If this value is set to TRue, only the request header portion of a request is sent to the server. If the server finds no problem with the header, it returns a 100-Continue response, and the data is then sent. Two trips are required. If the property is set to false, the initial request includes the headers and data. If it is rejected by the server, the data has been sent unnecessarily; if it is accepted, a second trip is not necessary.

Because Web Service calls tend to pass small amounts of data, it can be beneficial to turn this property off. Even if a request is rejected, only a small amount of data will have been sent.

The Nagle Algorithm

One way to improve network efficiency is to reduce the number of small data packets sent across a network. To accomplish this, the software layer controlling the underlying TCP (Transmission Control Protocol) connection attempts to accumulate, or buffer, small messages into a larger TCP segment before they are sent. The technique to do this is based on the Nagle algorithm.^[4]

^[4] RFC 896, "Congestion Control in IP/TCP Internetworks," by John Nagle, 1984.

The crux of the algorithm is that small amounts of data should continue to be collected by TCP until it receives acknowledgment to send the data. .NET institutes a delay of up to 200 milliseconds to collect additional data for a packet. For a typically small Web Service request, there may be no reason to include this delay. It's an option you can experiment with.

To set the Expect100Continue and UseNagleAlgorithm properties, it is necessary to get a reference to the ServicePoint object being used to handle the Web request. This is done in the proxy code on the client side. Refer to Listing 18-2, and you'll see that the proxy code consists of a class derived from the base SoapHttpClientProtocol class. By overriding the inherited GetWebRequest method, you can customize the WebRequest object before the request is sent to the Web Service.

Add the following code to override the GetWebRequest method. Inside the method, you use the Uri object to get the ServicePoint. Its properties can then be turned off or on to test performance:

 // Using System.Net must be added protected override WebRequest GetWebRequest( Uri uri) {    // Locate ServicePoint object used by this application    ServicePoint sp =          ServicePointManager.FindServicePoint(uri);    sp.Expect100Continue = false;    sp.UseNagleAlgorithm = false;    return WebRequest.Create(uri); } 

Working with Large Amounts of Data

Although the XML format offers a great deal of flexibility in representing data, it can place a potentially large burden on a network because of the large files that can be generated. Moreover, processing XML data can require extensive memory resources on the client and server. Finally, there is the nature of a Web Service: If the transmission fails at any point, the entire response must be resent. This is in contrast to FTP and the HTTP GET verb that allow partial data transmission.

For large amounts of data, consider these options:

• Use FTP or a Web client as described in Section 17.6, "Creating a Web Client with WebRequest and WebResponse."

• Avoid calls as much as possible by caching data rather re-requesting it.

• Look at compression techniques such as HTTP transport compression or the SOAP extensions that can compress part of a Web Service message.

• Wait for new Web Service standards. Of particular note is Message Transmission Optimization Mechanism (MTOM), a new W3C recommendation pushed by Microsoft that details a method for attaching large binary data to a SOAP message.