Performance Tuning and Optimizing ASP.NET Applications

Web services are always called remotely and are typically invoked using a SOAP request. This architecture by design creates a process boundary that automatically degrades the responsiveness of the Web service. In addition, Web services and their consumers are forced to take the extra processing step of assembling and parsing SOAP requests . By their nature, Web services will not respond as fast as locally installed components , so it is extra important that you take steps to maximize the performance of your Web service. You can do so with a few simple design optimizations:

• Use asynchronous Web method calls where possible : Asynchronous calls are ideal for intensive Web methods that take a significant time to process and where the consumer application has the flexibility to work on other things while it waits for a response from the Web service.

• Use timeouts for synchronous calls : Web methods should contain built-in timeouts in case the Web method hangs or takes an unusually long time to execute. This will prevent the client application from hanging indefinitely while it waits for the Web service call to return. In addition, you can set the Timeout property explicitly on the Web service client proxy class. Web service proxy classes implement a common base class called WebClientProtocol, which in turn provides a Timeout property. For example:

  Dim objWS As localhost.Northwind = New localhost.Northwind() ' Proxy Class objWS.Timeout = 15000 ' Set the Web method call timeout to 15 seconds

• Use output caching for responses : Output caching will improve the responsiveness and performance of a Web method. The WebMethod() attribute provides a CacheDuration property that specifies the number of seconds to cache an output response. Web service output caching varies by parameter, so users with different requests parameters will not receive the same cached response. Chapter 4, "Optimizing Application and Session State Management," discusses output caching in great detail and includes a section on Web services.

• Minimize traffic : Cross-process calls are expensive, so you should minimize the amount of traffic that flows between a Web service and its consumer. Use fewer Web methods that return more information vs. more Web methods that return limited, granular information. Avoid multiple consecutive Web method calls if you can accomplish the same result using a single Web method that returns more information.

• Minimize use of complex data types : Complex data types such as the ADO.NET DataSet provide a sophisticated level of information but come with a performance price. The DataSet object, for example, serializes to a large chunk of XML that requires intensive processing to serialize and to parse. By all means use these complex types if they make the most sense. But if they are not needed, then you are better off using simple types. For example, in our Web methods we typically map the contents of a DataSet to an array of simple types, such as an array of strings. This creates a smaller footprint than a serialized DataSet object.

• Use SOAP Headers for global information : If your Web service uses SOAP as its communication protocol, then you should consider using SOAP headers for passing certain types of information. SOAP headers are included within a SOAP envelope, but they are not tied to a specific Web method message. SOAP headers are useful for passing global values that apply to all Web methods. They generate a small footprint and do not clutter the WSDL definitions for individual Web methods. In addition, SOAP headers are useful for passing authentication information between a Web service and a consumer.

• Use client-side invocation : You have seen techniques for invoking Web services from client-side script using the WebService DHTML behavior. Client-side invocation minimizes server postbacks and may be the most efficient way to process user input, especially on pages with large view state or pages that accept input but do not display much information. For example, we typically design form input screens to process the update with a Web service. This design updates the information quickly and the form can be refreshed quickly using a client-side script.

• Code intelligently : Web services are simply another type of .NET application, so you should follow the same smart coding conventions that you use in other kinds of .NET applications. The conventions include, but are not limited to, the following: use early binding for object references, release object references as soon as you are done with them, and use casting to convert object references from one data type to another.

• Compile intelligently : ASP.NET automatically leverages the .NET Framework's optimized runtime system, which uses Just-In-Time (JIT) compilation to keep components loaded in memory only for as long as they are needed. Keep your Web services small and ensure that your Web methods remain logically partitioned between several Web services rather than in one large Web service. There is no quantitative measure to guide you here, besides stress testing results. Qualitatively, you can keep your Web services more responsive if they are smaller and can be loaded quickly by the JIT compiler. Remember to always switch the project's Build Configuration from Debug to Release before deployment. This will result in a smaller, faster executable that implements all of the chosen optimizations from the project property pages.

As a final thought, you may want to consider using .NET remoting as an alternative to Web services. .NET remoting is a technology for distributed programming that uses SOAP as one available protocol choice, in addition to binary remoting over TCP/IP. .NET remoting is a useful technology for passing binary objects across process boundaries, and it is usually much more efficient than Web services if you are generating complex objects and do not need to use SOAP. The .NET Framework provides efficient design patterns for .NET remoting solutions that provide sophisticated functionality with relatively little code. You can read more about .NET remoting in the .NET Framework Software Development Kit (SDK).