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.

1. Optimizing Web Service Design
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.
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.
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,

2. 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.
Author Bio: Spec India is a Custom Software Application Development and Software
Solutions Company based in Ahmedabad, India. Our Services includes iPhone
Application Development, Android Application Development, ORACLE, .Net, and
Mobile Computing.