The Web services platform in the .NET Framework is built with high performance in mind on IIS and System.Net; therefore, it can be quite fast. A number of common “gotchas” can arise, however, as you deploy Web services in a production environment that requires high performance. The performance tips given here will be discussed in detail in Chapter 14. The purpose of this section is to call out common elements that often apply to applications using Web services, so that they can be avoided.
100 Continue and POST
Because Web services are usually sent via an HTTP POST, they are subject to the 100 Continue logic, which will be described in Chapter 14. While 100 Continue is often the ideal semantic because it can save the client from sending data that doesn’t have to be sent, 100 Continue does cause an extra roundtrip between the client and the server for each Web-service call. If the data is small enough, it might be faster to simply turn off the 100 Continue feature for Web services. The 100 Continue feature is controlled via the System.Net.ServicePointManager.Expect100Continue property.
Pre-authentication can save time in cases in which the application repeatedly calls the same set of services. At least one major Web services client product sends basic authentication credentials with every request if pre-authentication is turned on in the client API. We know this because we occasionally get requests to do this for Web services calls. System.Net does not send the basic credentials on the first request when pre-authentication is enabled. This is because the client doesn’t know which authentication scheme is desired by the server until it has made at least one request to the server. Basic authentication alone provides little defense in terms of protection from credential theft. It would be unfortunate if the client sent basic credentials across the network when the server wanted some stronger form of authentication, such as Kerberos. In general, we recommend that basic authentication be used only if it is done in concert with some other encryption mechanism, such as HTTPS (Secure HTTP) or encryption at the network’s IP layer or lower. In cases where the environment is controlled, however, and the benefits of using basic authentication are deemed to outweigh the risks, you can add your own basic header to the Web service request using the custom header logic described earlier in this chapter.
In Visual Studio .NET the UnsafeAuthenticatedConnectionSharing property is exposed on each of the automatically generated client proxies. UnsafeAuthenticatedConnectionSharing is used in conjunction with the ConnectionGroupName property, which is also exposed on the Web services proxy. If the service is using authentication, these two properties can have a significant impact on the performance of your Web service, as they enable connection pooling for the authenticated connections. Be sure to use them carefully according to the description in Chapter 14.
Also notice that the System.Net connection semantics apply to Web service requests made with the .NET Framework. For example, setting the System.Net.ServicePointManager.DefaultConnectionLimit to 20 when the application domain is starting will cause all Web service requests to use a connection limit of 20 rather than the default of 2.
The Nagle algorithm increases network efficiency by decreasing the number of packets sent across the network. It accomplishes this by instituting a delay on the client of up to 200 milliseconds when small amounts of data are written to the network. The delay is a wait period for additional data that might be written. New data is added to the same packet. The practice of compiling data is not always ideal for Web services, however, because a POST request often contains a small amount of data in the HTTP headers without the body (because of 100 Continue, as described earlier). The Nagle algorithm can be turned off for Web services calls via the System.Net.ServicePointManager.UseNagleAlgorithm property. Yet disabling the Nagle algorithm might not provide the best performance either, you’ll need to experiment with disabling the algorithm to fine- tune your application. Whether you should disable the algorithm in this case depends on several factors, including the size of the Web services call, the latency of the network, and whether HTTP authentication is involved.
Certain decisions can significantly increase system scalability when using Web services. The following tips are related to managing the use of threads and connections within the system.
Developers who use the .NET Framework frequently call Web services from within ASP.NET. This practice is known as a “middle-tier” scenario. Because ASP.NET and System.Net share the same thread pool, however, the threads must be well managed when used together. When threads are not well managed, a middle-tier ASP.NET application that calls a Web service can run in an underutilized state while the server waits for available threads. An even worse outcome is a deadlocked application caused by ASP.NET worker threads waiting for back-end requests to complete. Back-end requests require additional threads to complete, so nothing can happen until the requests start to time out. An obvious way to guard against such thread starvation is to always move the methods being called into a local dynamic link library (DLL) and call them directly from code whenever possible.
However, an off-machine, Web services call is often necessary as part of processing an ASP.NET page. In this case, there are a number of concepts to keep in mind.
Another option available to middle-tier applications that need to call a Web service as a result of an ASP.NET page request is to use the asynchronous framework provided in ASP.NET to include a module that issues the request asynchronously before the page starts to load. This way, the server will have no threads blocking while I/O completes and pages will have the necessary data when they load. This option is fairly complex, but it can enable applications to get the most out of the available resources on the server. The following sample projects demonstrates a page that uses an asynchronous module to call a Web service and process a request with ASP.NET support for asynchronous modules. The samples are given in C# and VB .NET.
In this exercise we will create an ASP web service application and then we will try to create an asynchronous module. Later we will load our own asynchronous module when an asp page is accessed. Take note that we will create the C# solution which contains both projects (ASP web service and asynchronous module) directly under the IIS web server root directory by assuming the IIS already configured and running.
Create a new C# ASP .NET Web Service Application.
You can use the AuthServiceCS as the solution and project name if you want. Make sure the project is put under the C:\Inetpub\wwwroot folder. The C:\Inetpub\wwwroot is the default IIS physical web root folder.
The ASP web service project template was given for us to customize it as shown in the following screenshot.
Add the following using directive and delete other un-use using directive.
Change the tempuri.org Namespace:
|[WebService(Namespace = "http://tempuri.org/")]|
To localhost URI. In real development, this should be your real URI.
|[WebService(Namespace = "http://localhost/")]|
Add/edit the code as shown below.
/// Summary description for Service1
[WebService(Namespace = "http://localhost/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
// To allow this Web Service to be called from script, using ASP.NET AJAX, uncomment the following line.
public class Service1 : WebService
public int Sum(int lhs, int rhs)
return lhs + rhs;
public bool IsAuthorized(string userName)
// shun John, let everyone else in
Regex r = new Regex("john", RegexOptions.IgnoreCase);
Match m = r.Match(userName);
Next, build the project. Make sure there is no error.
Then debug (run in Debug mode) the project. Make sure there is no error.
Select the first radio button. Visual Studio will enable the debugging setting in the Web.config file. This setting must be disabled in the real deployment. Most of the web activities for a web application can be controlled through Web.config settings and can also be overrided by the ASP codes programmatically.
When you double-click the Web.config file, the debug setting will be changed to "true" value as shown below.
The following is the web service test page run in the ASP .NET development server.
Let do some testing. Click the IsAuthorized link (web method). Type in any name (value) other than John in the userName (parameter) text box and click the Invoke button.
The result is displayed in XML format. In the real application development and deployment we need to create a page for the value input and the result. Notice also the URL in the browser address bar.