1.Web Services Implementation Considerations
1.1 Approaches to caching

Caching is a great way to improve Web service performance. By reducing the average request time and easing server load, caching also helps scalability. Frequently used data applicable to all users or SOAP response output can be cached. Application data can be cached by using ASP.NET caching features. SOAP output can be cached by either using the ASP.NET output cache or by employing perimeter caching. When designing a caching strategy for a Web service, consider the following guidelines:

• Use output caching with the CacheDuration property
• Consider providing cache related information to clients
• Consider perimeter caching

Use Output Caching with the CacheDuration Property

If portions of the output are static or nearly static use ASP.NET output caching, ASP.NET output caching must be used with Web services, by configuring the CacheDuration property of the WebMethod attribute. The following code shows an example where the cache duration is set to 30 seconds

[WebMethod(CacheDuration=30)]
public string SomeMethod() { … }

Consider Providing Cache Related Information to Clients

The clients of the Web service can also implement custom caching solution which caches the response from the web service. If the clients of the web service are expected to cache the response, consider providing cache expiration related information to the clients so that they send new requests to the Web service only after their cached data has expired. Additional field can be added in the Web service response that specifies the cache expiration time.

Consider Perimeter Caching

If the output from the web service changes infrequently, hardware or software (ISA firewall) to cache the response at the perimeter network can be used. Perimeter caching will respond before the request even reaches the web server reducing the amount of requests that need to be serviced by the web servers.

1.2 Serialization Considerations

Serialization is an important issue from the web services’ performance point of view since web services uses XML in SOAP messages.

1.2 .1 Reduce Serialization with XmlIgnore

To limit which fields exposed by an object are serialized when the object is passed to or from a Web method and to reduce the amount of data sent over the wire, the XmlIgnore attribute should be used as shown below. The XmlSerializer class ignores any field annotated with this attribute. Please note that XmlIgnore serializes only public members unlike the formatters derived from IFormatter interface.

// This is the class that will be serialized.
public class MyClass
{
// The str1 value will be serialized.
public string str1;

/* This field will be ignored when serialized–
unless it’s overridden. */
[XmlIgnoreAttribute]
public string str2;
}

1.2.2 Cache the XmlSerializer to Reduce Construction Overhead

Constructing an XmlSerializer is a costly operation. During construction it performs the following operations:

• It analyzes all of the types that are passed to it.

• It generates some C# code to serialize the object and then launches the C# compiler to compile it. This overhead will be reduced in future versions of the .NET Framework.

To improve performance, it must be made sure that the reference to the XmlSerializer object is cached to avoid the construction overhead for each Web request.

For more information, see “XmlSerializer Architecture” in the November 2001 edition of MSDN magazine.

1.2.3 Reduce Round Trips

Reducing the round trips to the web service reduces the number of times the flow needs to cross serialization boundaries. This helps reduce the overall serialization cost incurred. Some of the design options which help reduce round trips are:

• Message based interaction for the web service must be considered.

• Consider having a data façade for the out parameters which serve as a data contract with the clients. This helps sending all the relevant data to the clients by receiving one single request rather than sending the data on multiple requests.

1.2.4 Consider XML Compression

Compressing the XML payload sent over the wire helps reduce the network traffic significantly. Xml compression can be implemented by using one of the following

• Implementing and using SOAPExtensions both on the server and client side for compression and decompression of both the request and the response.

• Implementing a custom HttpModule on the server and overriding the proxy for the web service on the client side.

• Using Http compression features available in IIS 5.0 and greater versions for compressing the response from the web service. You still need a decompression mechanism on the client.

1.3 Connection Performance Considerations

When Web services are called, TCP connections are pooled by default. If a connection is available from the pool it is used, otherwise a new connection is created up to a configurable limit. There is always a default unnamed connection pool. A connection group is a way to isolate a connection pool used by a given set of HTTP requests. Separate pools can be used by specifying a ConnectionGroupName when requests are made; otherwise the default connection pool is used. To use connections efficiently, it is necessary to set an appropriate number of connections, determine whether connections will be reused, and factor in security implications.

The following recommendations improve connection performance:
1. Configure maxconnections
2. Prioritize and allocate connections across discreet Web services
3. Use a single identity for outbound calls
4. Use PreAuthenticate with Basic authentication

1.3.1 Configure maxconnections

‘maxconnection’ limits the number of concurrent outbound calls. It does not apply to local requests. The default limit is 2 per Connection Group specified by the maxconnection attribute in machine.config or the application configuration file. For desktop applications calling Web services, 2 connections may be sufficient. For ASP.NET applications calling Web services, 2 is generally not enough.

Change the maxconnection attribute from 2 to 12 per CPU as a starting point:
<connectionManagement>
<add address=”*” maxconnection=”12″/>
</connectionManagement>

Note that 12 connections is an arbitrary number, but empirical evidence has shown that 12 connections are optimal for a variety of scenarios when ASP.NET is also limited to 12 concurrent requests. It is necessary to validate the appropriate number of connections for a given scenario.

1.3.2 Prioritize and Allocate Connections across Discreet Web Services

Enumerate and prioritize the Web services that need to be called. Allocate more connections to the critical Web services. Each Web service is specified using the address attribute as follows:

<connectionManagement>
<add address=”WebServiceA” maxconnection=”8″>
<add address=”WebServiceB” maxconnection=”4″>
</connectionManagement>

For example, if the application typically makes more requests to WebServiceA than WebServiceB, one can dedicate more connections, as seen in the example above.

1.3.3 Use a Single Identity for Outbound Calls

Single trusted identity must be used for making Web service calls wherever it is possible. This helps to limit the number of separate pools. While there is a need to create separate pools of connections for different discreet Web services, avoid creating pools per user. If there is a need to create pools per user, then specify a ConnectionGroupName when the Web service is called, but this will hurt performance and lead to a large number of pools.

The connection pool the call uses is not determined by the identity of the caller. The ConnectionGroupName determines which connection pool is used. If separate identities use the same ConnectionGroupName, they will use the same pool of connections. It may be neccessary to create separate pools of connections for different discreet Web services or if the identity of the original caller is flown.

If ASP.NET calls Web services that allow anonymous, connections from the default connection pool will be used. This is the default behavior unless a ConnectionGroupName is specified.

1.3.4 Use ‘PreAuthenticate’ with Basic Authentication

If Basic authentication is used, the proxy’s ‘PreAuthenticate’ property can be set to true or false. Set it to true to supply specific authentication credentials to cause a WWW-authenticate HTTP header to be passed with the Web request. This saves the Web server denying access on the request, and performing authentication on the subsequent retry request.

Note Pre-authentication only applies after the Web service successfully authenticates the first time. Pre-authentication has no impact on the first Web request.