smartcn

Improving Web Services Performance

Improving .NET Application Performance and Scalability

J.D. Meier, Srinath Vasireddy, Ashish Babbar, and Alex Mackman
Microsoft Corporation

May 2004

Related Links

Home Page for Improving .NET Application Performance and Scalability

Chapter 5, Improving Managed Code Performance

Checklist: Web Services Performance

Send feedback to [email protected]

patterns & practices Library

Summary: This chapter focuses on design guidelines and techniques, such as state management, asynchronous invocation, serialization, threading, to help you develop efficient Web services. This chapter also presents a formula for reducing thread contention and HTTP connections to increase the throughput for your Web services.

Objectives
Overview
How to Use This Chapter
Architecture
Prescriptive Guidance for Web Services, Enterprise Services, and .NET Remoting
Performance and Scalability Issues
Design Considerations
Implementation Considerations
Connections
Threading
One-Way (Fire-and-Forget) Communication
Asynchronous Web Methods
Asynchronous Invocation
Timeouts
WebMethods
Serialization
Caching
State Management
Bulk Data Transfer
Attachments
COM Interop
Measuring and Analyzing Web Services Performance
Web Service Enhancements
Summary
Additional Resources

Objectives

Identify top Web services performance issues.
Design scalable Web services that meet your performance objectives.
Improve serialization performance.
Configure the HTTP runtime for optimum performance.
Improve threading efficiency.
Evaluate and choose the most appropriate caching mechanism.
Decide when to maintain state.
Evaluate and choose the most appropriate bulk data transfer mechanism.

Overview

Services are the ideal communication medium for distributed applications. You should build all of your services using Web services and then, if necessary, use Enterprise Services or Microsoft® .NET remoting within the boundaries of your service implementation. For example, you might need to use Enterprise Services for distributed transaction support or object pooling.

Web services are ideal for cross-platform communication in heterogeneous environments because of their use of open standards such as XML and Simple Object Access Protocol (SOAP). However, even in a closed environment where both client and server systems use the .NET Framework, ease of deployment and maintenance make Web services a very attractive approach.

This chapter begins by examining the architecture of ASP.NET Web services, and then explains the anatomy of a Web services request from both the client and server-side perspectives. You need a solid understanding of both client and server to help you identify and address typical Web services performance issues. An understanding of Web services architecture will also help you when you configure the HTTP runtime to optimize Web services performance. The chapter then presents a set of important Web services design considerations, followed by a series of sections that address the top Web services performance issues.

How to Use This Chapter

To get the most out of this chapter:

Jump to topics or read from beginning to end. The main headings in this chapter help you to locate the topics that interest you. Alternatively, you can read the chapter from beginning to end to gain a thorough appreciation of performance and scalability design issues.
Use the checklist. Use "Checklist: Web Services Performance" in the "Checklists" section of this guide to quickly view and evaluate the guidelines presented in this chapter.
Use the "Architecture" section of this chapter to learn how Web services work. By understanding Web services architecture, you can make better design and implementation choices.
Use the "Design Considerations" section of this chapter. This section helps you to understand the higher-level decisions that affect implementation choices for Web services code.
Read Chapter 6, "Improving ASP.NET Performance" Many of the performance optimizations described in Chapter 6, "Improving ASP.NET Performance" — such as tuning the thread pool and designing and implementing efficient caching — also apply to ASP.NET Web services development.
Read Chapter 13, "Code Review: .NET Application Performance" See the "Web Services" section of Chapter 13 for specific guidance.
Measure your application performance. Read the "Web Services" and ".NET Framework Technologies" sections of Chapter 15, "Measuring .NET Application Performance" to learn about key metrics that you can use to measure application performance. It is important that you are able to measure application performance so that you can target performance issues accurately.
Test your application performance. Read Chapter 16, "Testing .NET Application Performance" to learn how to apply performance testing to your application. It is important that you apply a coherent testing process and that you are able to analyze the results.
Tune your application performance. Read the "Web Services" section of Chapter 17, "Tuning .NET Application Performance" to learn how to resolve performance issues identified through the use of tuning metrics.

Architecture

The server-side infrastructure is based on ASP.NET and uses XML serialization. When the Web server processes an HTTP request for a Web service, Internet Information Services (IIS) maps the requested extension (.asmx) to the ASP.NET Internet server application programming interface (ISAPI) extension (Aspnet_isapi.dll). The ASP.NET ISAPI extension then forwards the request to the ASP.NET worker process, where it enters the request processing pipeline, which is controlled by the HttpRuntime object. See Figure 10.1 for an illustration of the Web services architecture and request flow.

Figure 10.1: ASP.NET Web services architecture and request flow

The request is initially passed to the HttpApplication object, followed by the series of registered HttpModule objects. HttpModule objects are registered in the system-wide Machine.config file or in the <httpModules> section of an application-specific Web.config file. HttpModule objects handle authentication, authorization, caching, and other services.

After passing through the HTTP modules in the pipeline, HttpRuntime verifies that the .asmx extension is registered with the WebServiceHandlerFactory handler. This creates an HTTP handler, an instance of a type that derives from WebServiceHandler, which is responsible for processing the Web services request. The HTTP handler uses reflection to translate SOAP messages into method invocations. WebServiceHandler is located in the System.Web.Services.Protocols namespace.

Client-Side Proxy Classes

On the client side, proxy classes provide access to Web services. Proxy classes use XML serialization to serialize the request into a SOAP message, which is then transported using functionality provided by the System.Net namespace.

You can use the Wsdl.exe tool to automatically generate the proxy class from the Web Services Description Language (WSDL) contract file. Depending on the bindings specified in the WSDL, the request issued by the proxy may use the HTTP GET, HTTP POST, or HTTP SOAP protocols.

The proxy class is derived from one of the following base classes:

System.Web.Services.Protocols.HttpGetClientProtocol
System.Web.Services.Protocols.HttpPostClientProtocol
System.Web.Services.Protocols.SoapHttpClientProtocol

These all derive from System.Web.Services.Protocols.HttpWebClientProtocol, which in turn derives from the System.Web.Services.Protocols.WebClientProtocol base class in the inheritance chain. WebClientProtocol is the base class for all automatically generated client proxies for ASP.NET Web services, and, as a result, your proxy class inherits many of its methods and properties.

Prescriptive Guidance for Web Services, Enterprise Services, and .NET Remoting

Services are the preferred communication technique to use across application boundaries, including platform, deployment, and trust boundaries. You can implement services today by using Web services or Web Services Enhancements (WSE). Although WSE provides a rich set of features, you should evaluate whether or not you can accept the WSE support policy. Enterprise Services provides component services such as object pooling, queued components, a role-based security model and distributed transactions, and should be used as an implementation detail within your service when you need those features. .NET remoting is preferred for cross-application communication within the same process.

Object Orientation and Service Orientation

When you design distributed applications, use the services approach whenever possible. Although object orientation provides a pure view of what a system should look like and is effective for producing logical models, an object-based approach can fail to consider real-world factors, such as physical distribution, trust boundaries, and network communication, as well as nonfunctional requirements, such as performance and security.

Table 10.1 summarizes some key differences between object orientation and service orientation.

Table 10.1: Object Orientation vs. Service Orientation

Object Orientation	Service Orientation
Assumes a homogeneous platform and execution environment.	Assumes a heterogeneous platform and execution environment.
Shares types, not schemas.	Shares schemas, not types.
Assumes cheap, transparent communication.	Assumes variable cost, explicit communication.
Objects are linked: object identity and lifetime are maintained by the infrastructure.	Services are autonomous: security and failure isolation are a must.
Typically requires synchronized deployment of both client and server.	Allows continuous, separate deployment of client and server.
Is easy to conceptualize and thus provides a natural model to follow.	Builds on ideas from component software and distributed objects. Dominant theme is to manage/reduce sharing between services.
Provides no explicit guidelines for state management and ownership.	Owns and maintains state or uses the reference state.
Assumes a predictable sequence, timeframe, and outcome of invocations.	Assumes message-oriented, potentially asynchronous, and long-running communications.
Goal is to transparently use functions and types remotely.	Goal is to provide inter-service isolation and wire interoperability based on standards.

Application Boundaries

Common application boundaries include platform, deployment, trust, and evolution. (Evolution refers to whether or not you develop and upgrade applications together.) When you evaluate architecture and design decisions that affect your application boundaries, consider the following:

Objects and remote procedure calls (RPC) are appropriate within boundaries.
Services are appropriate across and within boundaries.

Recommendations for Web Services, Enterprise Services, and .NET Remoting

When you are working with ASP.NET Web services, Enterprise Services, and .NET remoting, Microsoft recommends that you:

Build services by using ASP.NET Web Services.
Enhance your ASP.NET Web services with WSE if you need the WSE feature set and you can accept the support policy.
Use object technology, such as Enterprise Services or .NET remoting, within a service implementation.
Use Enterprise Services inside your service boundaries in the following scenarios:
- You need the Enterprise Services feature set (such as object pooling; declarative, distributed transactions; role-based security; and queued components).
- You are communicating between components on a local server and you have performance issues with ASP.NET Web services or WSE.
Use .NET remoting inside your service boundaries in the following scenarios:
- You need in-process, cross-application domain communication. Remoting has been optimized to pass calls between application domains extremely efficiently.
- You need to support custom wire protocols. Understand, however, that this customization will not port cleanly to future Microsoft implementations.

Caveats

When you work with ASP.NET Web services, Enterprise Services, or .NET remoting, consider the following caveats:

If you use ASP.NET Web services, avoid or abstract your use of low-level extensibility features such as the HTTP Context object.
If you use .NET remoting, avoid or abstract your use of low-level extensibility such as .NET remoting sinks and custom channels.
If you use Enterprise Services, avoid passing object references inside Enterprise Services. Also, do not use COM+ APIs. Instead, use types from the System.EnterpriseServices namespace.

More Information

For guidelines on how to make .NET Enterprise Services components execute as quickly as C++ COM components, see the MSDN® article, ".NET Enterprise Services Performance," at http://msdn.microsoft.com/library/en-us/dncomser/html/entsvcperf.asp.
For more information on Enterprise Services, see Chapter 8, "Improving Enterprise Services Performance"
For more information on remoting, see Chapter 11, "Improving Remoting Performance"

Performance and Scalability Issues

The main issues that can adversely affect the performance and scalability of your Web services are summarized in the following list. Subsequent sections in this chapter provide strategies and technical information to prevent or resolve each of these issues.

Incorrect communication mechanism. Currently, there are three main technologies for remoting a method call: Enterprise Services, .NET remoting, and ASP.NET Web services. The best choice depends upon various factors, including the source and target platforms, whether you need to communicate across an intranet or the Internet, whether you require additional services such as distributed transactions, your security requirements, deployment considerations (such as whether your communication must pass through a firewall), other port limitations, and so on.
- Web services. Use Web services to build your services.
- Enterprise Services. If you use Web services to build your services, you may still need to use Enterprise Services within your service implementation. For example, you may need it to support distributed transactions or if you want to use object pooling.
- .NET remoting. Use remoting for same-process, cross-application domain communication or for remote communication if you need to integrate with a legacy protocol. If you use remoting, avoid custom proxies, custom sinks, and using contexts. This helps to avoid compatibility issues with future communication technologies.
Chatty calls. Network round trips to and from a Web service can be expensive. This issue is magnified if clients need to issue multiple requests to a Web service to complete a single logical operation.
Improper choice of parameters. Your choice of parameters depends upon various factors, such as interoperability, the varying platforms used by the clients, maintainability, the type of encoding format used, and so on. Improper choice of parameters can lead to a number of issues, including increased serialization costs and potential versioning problems for the Web service (for example where a custom type is updated). Where possible, you should use primitive types. If interoperability is an issue, consider using the XmlElement and XmlDocument types and choose types specific to your application, such as an Employee or Person class.
Serialization. Serializing large amounts of data and passing it to and from Web services can cause performance-related issues, including network congestion and excessive memory and processor overhead.
Other issues that affect the amount of data passed across the wire include improper data transfer strategies for large amounts of data. Selecting an appropriate data transfer strategy — such as using a SOAP extension that performs compression and decompression or offloading data transfer to other services — is critical to the performance of your Web services solution.
Improper choice of encoding format. You can use either literal or SOAP encoding. SOAP encoding involves more SOAP-processing overhead as compared to literal encoding.
Lack of caching or inefficient caching. In many situations, application or perimeter caching can improve Web services performance. Caching-related issues that can significantly affect Web services performance include failure to use caching for Web methods, caching too much data, caching inappropriate data, and using inappropriate expiration settings.
Inefficient state management. Inefficient state management design in Web services can lead to scalability bottlenecks because the server becomes overloaded with state information that it must maintain on a per-user basis. Common pitfalls for Web services state management include using stateful Web methods, using cookie container–based state management, and choosing an inappropriate state store. The most scalable Web services maintain no state.
Misuse of threads. It is easy to misuse threads. For example, you might create threads on a per-request basis or you might write code that misuses the thread pool. Also, unnecessarily implementing a Web method asynchronously can cause more worker threads to be used and blocked, which affects the performance of the Web server.
On the client side, consumers of Web services have the option of calling Web services asynchronously or synchronously. Your code should call a Web service asynchronously only when you want to avoid blocking the client while a Web service call is in progress. If you are not careful, you can use a greater number of worker and I/O threads, which negatively affects performance. It is also slower to call a service asynchronously; therefore, you should avoid doing so unless your client application needs to do something else while the service is invoked.
Inefficient Web method processing. A common example of inefficient processing is not using a schema to validate input upfront. This issue can be significant because the Web method may de-serialize the incoming message and then throw exceptions later on while processing the input data.

Design Considerations

To help ensure that you create efficient Web services, there are a number of issues that you must consider and a number of decisions that you must make at design time. The following are major considerations:

Design chunky interfaces to reduce round trips.
Prefer message-based programming over RPC style.
Use literal message encoding for parameter formatting.
Prefer primitive types for Web services parameters.
Avoid maintaining server state between calls.
Consider input validation for costly Web methods.
Consider your approach to caching.
Consider approaches for bulk data transfer and attachments.
Avoid calling local Web services.

Design Chunky Interfaces to Reduce Round Trips

Design chunky interfaces by exposing Web methods that allow your clients to perform single logical operations by calling a single Web method. Avoid exposing properties. Instead, provide methods that accept multiple parameters to reduce roundtrips.

Do not create a Web service for each of your business objects. A Web service should wrap a set of business objects. Use Web services to abstract these objects and increase the chunkiness of your calls.

Prefer Message-Based Programming Over RPC Style

You can design Web services by using either of two programming models: messaging style and RPC style. The RPC style is based on the use of objects and methods. Web methods take object parameters to do the processing, and then return the results. This style generally relies on making multiple Web method calls to complete a single logical operation, as shown in the following code snippet.

//client calling a Web service
Serv.SendItemsToBePurchased(Array[] items);
Serv.ShippingAddress(string Address);
Serv.CheckOut();

The messaging style does not focus on objects as parameters. It is based on a data contract (schema) between the Web service and its clients. The Web service expects the message to be XML that conforms to the published data contract.

//Client
string msg = "<Items>…</Items>";
MyMethod(msg);

//Server
[WebMethod]
void MyMethod(string msg){ . . . }

This approach allows you to package and send all parameters in a single message payload and complete the operation with a single call, thus reducing chatty communication. The Web service may or may not return results immediately; therefore, the clients do not need to wait for results.

Use Literal Message Encoding for Parameter Formatting

The encoded formatting of the parameters in messages creates larger messages than literal message encoding (literal message encoding is the default). In general, you should use literal format unless you are forced to switch to SOAP encoding for interoperability with a Web services platform that does not support the literal format.

Prefer Primitive Types for Web Services Parameters

There are two broad categories of parameter types that you can pass to Web services:

Strongly typed. These include .NET types such as double and int, and custom objects such as Employee, Person, and so on. The advantage of using strongly typed parameters is that .NET automatically generates the schema for these types and validates the incoming values for you. Clients use the schema to construct appropriately formatted XML messages before sending them.
Loosely typed. These parameters use the string type. Note that you should not pass XML documents as string parameters because the entire string then needs to be XML encoded. For example, < and > needs to be converted to &lt and &gt and so on. Instead, you should use either an XmlElement parameter or implement IXmlSerializable. The latter is the most efficient and works well for large data sizes, regardless of which encoding style you use, you should prefer simple primitive types like int, double, and string for Web services parameters. Use of primitive types leads to reduced serialization and automatic and efficient validation by the .NET Framework.

Avoid Maintaining Server State Between Calls

Maintaining per-caller state in memory on the server limits scalability because the state consumes server resources. As an alternative, you can pass state back and forth between the client and Web service. Although this approach enables you to scale your service, it does add performance overhead — including the time taken to serialize, transmit, parse, and de-serialize the state with each call.

Consider Input Validation for Costly Web Methods

If you have a Web method that performs costly and time-consuming processing, consider validating the Web method input before processing it. It can be more efficient to accept the validation overhead to eliminate unnecessary downstream processing. However, unless you are likely to receive invalid input frequently, you should probably avoid schema validation due to the significant overhead that it introduces. You need to assess your specific situation to determine whether or not schema validation is appropriate.

You can validate input data either by using SOAP extensions or by using separate internal helper methods that your Web methods call. The advantage of using SOAP extensions is that they permit you to separate your validation code from your business logic. If there is any schema change in the future, the extension can change independently of the Web method.

Another option is to use the XmlValidatingReader class to perform schema-based validation, as shown in the following code snippet.

[WebMethod]
public void ValidateCreditCard(string xmlCardInfo){
  try
  {
    // Create and load a validating reader
    XmlValidatingReader reader = new XmlValidatingReader(xmlCardInfo,
                                                       
XmlNodeType.Element, null);

    // Attach the XSD schema to the reader
    reader.Schemas.Add(
           "urn:CardInfo-schema",@"http://localhost/Card/Cardschema.xsd");

    // Set the validation type for XSD schema.
    // XDR schemas and DTDs are also supported
    reader.ValidationType = ValidationType.Schema;

    // Create and register an event handler to handle validation errors
    reader.ValidationEventHandler += new ValidationEventHandler(
                                                        ValidationErrors );

    // Process the input data
    while (reader.Read())
    {
    . . .
    }

    // Validation completed successfully
  }
  catch

  { . . .}
}
// Validation error event handler
private static void ValidationErrors(object sender, ValidationEventArgs args)
{
  // Error details available from args.Message
  . . .
}

Consider Your Approach to Caching

You can greatly enhance Web services performance by caching data. With ASP.NET Web services, you can use many of the same caching features that are available to ASP.NET applications. These include ASP.NET output caching, HTTP response caching, and ASP.NET application caching.

In common with any caching solution, your caching design for a Web service must consider issues such as how frequently the cached data needs to be updated, whether or not the data is user-specific or application-wide, what mechanism to use to indicate that the cache needs updating, and so on. For more information about caching with Web services, see the "Caching" section later in this chapter.

Consider Approaches for Bulk Data Transfer and Attachments

You can use the following approaches to optimize the performance of bulk data transfer:

Chunking. With this approach, you use fixed-size byte arrays to send the data one chunk at a time.
Offloading the transfer. With this approach, you return a URL from your Web service which points to the file to be downloaded.
Compression. You can use a SOAP extension to compress the SOAP messages before transmitting them. This helps when you are constrained primarily by network bandwidth or latency.

To handle attachments, your options include:

WS-Attachments
Base 64 encoding
SOAP Message Transmission Optimization Mechanism (MTOM)

More Information

For more information about these approaches, see the "Bulk Data Transfer" and "Attachments" sections later in this chapter.

Avoid Calling Local Web Services

Web services located on the same computer as a client ASP.NET application share the same thread pool with the ASP.NET application. Therefore, the client application and the Web service share the same threads and other related resources, such as CPU for request processing. Calling a local Web service also means that your request travels through the entire processing pipeline and incurs overhead, including serialization, thread switching, request queuing, and de-serialization.

In addition, the maxconnection attribute of Machine.config has no affect on the connection limit for making calls to local Web services. Therefore, local Web services always tend to give preference to the requests that come from the local computer over requests that come from other machines. This degrades the throughput of the Web service for remote clients.

There are two main approaches to solving this problem:

Factor out the Web services business logic into a separate assembly, and call the assembly from the client application as well as the Web service.
Load the Web services assembly directly and call its methods. This approach is not as intuitive as the first.

More Information

For IIS 6.0 – specific deployment mitigation, refer to "ASP.NET Tuning" in Chapter 17, "Tuning .NET Application Performance"
For more information about how to structure your application properly, refer to "Application Architecture for .NET: Designing Applications and Services" on MSDN at http://msdn.microsoft.com/library/en-us/dnbda/html/distapp.asp.

Implementation Considerations

When you move from application design to development, consider the implementation details of your Web services. Important Web services performance measures include response times, speed of throughput, and resource management:

You can reduce request times and reduce server load by caching frequently used data and SOAP responses.
You can improve throughput by making effective use of threads and connections, by optimizing Web method serialization, and by designing more efficient service interfaces. Tune thread pooling to reduce contention and increase CPU utilization. To improve connection performance, configure the maximum limit of concurrent outbound calls to a level appropriate for the CPU performance.
You can improve resource management by ensuring that shared resources, such as connections, are opened as late as possible and closed as soon as possible, and also by not maintaining server state between calls.

By following best practice implementation guidelines, you can increase the performance of Web services. The following sections highlight performance considerations for Web services features and scenarios.

Connections

When you call Web services, transmission control protocol (TCP) connections are pooled by default. If a connection is available from the pool, that connection is used. If no connection is available, a new connection is created, up to a configurable limit. There is always a default unnamed connection pool. However, you can use connection groups to isolate specific connection pools used by a given set of HTTP requests. To use a separate pool, specify a ConnectionGroupName when you make requests. If you don't specify a connection group, the default connection pool is used. To use connections efficiently, you need to set an appropriate number of connections, determine whether connections will be reused, and factor in security implications.

The following recommendations improve connection performance:

Configure the maxconnection attribute.
Prioritize and allocate connections across discrete Web services.
Use a single identity for outbound calls.
Consider UnsafeAuthenticatedConnectionSharing with Windows Integrated Authentication.
Use PreAuthenticate with Basic authentication.

Configure The maxconnection Attribute

The maxconnection attribute in Machine.config limits the number of concurrent outbound calls.

Note This setting does not apply to local requests (requests that originate from ASP.NET applications on the same server as the Web service). The setting applies to outbound connections from the current computer, for example, to ASP.NET applications and Web services calling other remote Web services.

The default setting for maxconnection is two per connection group. For desktop applications that call Web services, two connections may be sufficient. For ASP.NET applications that call Web services, two is generally not enough. Change the maxconnection attribute from the default of 2 to (12 times the number of CPUs) as a starting point.

<connectionManagement>
  <add address="*" maxconnection="12"/>
</connectionManagement>

Note that 12 connections per CPU is an arbitrary number, but empirical evidence has shown that it is optimal for a variety of scenarios when you also limit ASP.NET to 12 concurrent requests (see the "Threading" section later in this chapter). However, you should validate the appropriate number of connections for your situation.

Increasing the maxconnection attribute results in increased thread pool and processor utilization. With the increase in the maxconnection value, a higher number of I/O threads will be available to make outbound concurrent calls to the Web service. As a result, you process incoming HTTP requests more quickly.

Before Making the Change

You should consider increasing the connections only if you have available CPU. You should always check processor utilization before increasing the attribute because increasing the attribute results in more work for the processor, as described above. For this reason, increasing this attribute makes sense only when your processor utilization is below the threshold limits (usually less than 75 percent utilization).

For more information, see the "Threading" section later in this chapter.

Evaluating the Change

Changing the attribute may involve multiple iterations for tuning and involves various trade-offs with respect to thread pool utilization. Therefore, the changes in the maxconnection attribute may require changes to other thread pool – related configuration attributes, such as maxWorkerThreads and maxIoThreads.

When you load test your application after making the configuration changes, you should monitor CPU utilization and watch the ASP.NET Applications/Requests/Sec and ASP.NET Applications/Requests in Application Queue performance counters. Requests in Application Queue should decrease while Requests/Sec and CPU utilization should increase.

Prioritize and Allocate Connections Across Discrete Web Services

Enumerate and prioritize the Web services you call. Allocate more connections to your critical Web services. You specify each Web service by using the address attribute as follows.

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

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

Use a Single Identity for Outbound Calls

Use a single trusted identity for making Web services calls where you can. This helps limit the number of separate connection pools. Although you may need to create separate pools of connections for different discrete Web services, avoid creating pools per user. If you need to create pools per user, then specify a ConnectionGroupName when you call the Web service, but be aware that this hurts performance and leads to a large number of pools.

The connection pool your 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 use the same pool of connections, as shown in the following code snippet.

// Create a secure group name.
….
serv = new WebService1();

// Set the PreAuthenticate property to send the authenticate request in 
first go
serv.PreAuthenticate=true;

// Set the client side credentials
ICredentials conCredentials = 
                 new NetworkCredential("UserId","Password","NPSTest" );
serv.Credentials = conCredentials;

// Do not allow the server to auto redirect as this may compromise security
serv.AllowAutoRedirect=false;
// Use the same connectionGroup Name for all the calls
serv.ConnectionGroupName = "SameForAllUsers";

You may need to create separate pools of connections for different discrete Web services or if you flow the identity of the original caller.

If ASP.NET calls Web services that allow anonymous callers, connections from the default connection pool are used. This is the default behavior unless you specify a ConnectionGroupName, as shown in above example.

Consider UnsafeAuthenticatedConnectionSharing with Windows Integrated Authentication

If your ASP.NET application calls a Web service that uses Microsoft Windows® integrated authentication, consider enabling UnsafeAuthenticatedConnectionSharing. By default, when you connect using Windows Integrated authentication, connections are opened and closed per request. This means that connections are not pooled by default. By enabling UnsafeAuthenticatedConnectionSharing, you keep connections open so they can be reused.

Consider the following guidelines:

If you are in a trusted environment and you connect using a single trusted identity, consider improving performance by setting UnsafeAuthenticatedConnectionSharing to true.

//set the UnsafeAuthenticatedConnectionSharing to true
myWebService.UnsafeAuthenticatedConnectionSharing = true;
NetworkCredential myCred = new 
NetworkCredential("UserA","PasswordA","DomainA");
CredentialCache myCache = new CredentialCache();
myCache.Add(new Uri("http://Someserver/WS/service1.asmx"), "NTLM", 
myCred);
myWebService.Credentials = myCache;
myWebService.ConnectionGroupName = "SameName";
string result = myWebService.HelloWorld();

//as the ConnectionGroupName property is same for different client requests //only the first connection from above gets authenticated
// the request below reuses the connection from above
myCred = new NetworkCredential("UserB","PasswordB","DomainB");
CredentialCache myCache = new CredentialCache();
myCache.Add(new Uri("http://Someserver/WS/service1.asmx"), "NTLM", 
myCred);
myWebService.Credentials = myCache;
myWebService.ConnectionGroupName = "SameName";
result = myWebService.HelloWorld();

If you call a Web service by using the ASP.NET application original caller's identity, then you should avoid enabling UnsafeAuthenticatedConnectionSharing because connections would be shared across calls. Alternatively, you can enable UnsafeAuthenticatedConnectionSharing, and then assign users to individual connection groups by using a ConnectionGroupName. Either option is inefficient and results in a high number of pools.
If you need to connect to separate discrete Web services, assign calls to separate pools using ConnectionGroupName.
If you need to connect to a server that uses AuthPersistence (it authenticates a whole connection and not a single request), then you should set UnsafeAuthenticatedConnectionSharing to true, and specify some random connection group name. You will need to determine which application requests will go to that connection group because the server will no longer challenge for authentication on that connection.

More Information

For more information about AuthPersistence, see Microsoft Knowledge Base article 318863, "HOW TO: Modify the AuthPersistence Metabase Entry Controls When Clients Are Authenticated," at http://support.microsoft.com/default.aspx?scid=kb;en-us;318863.
For more information on UnsafeAuthenticatedConnectionSharing, see the .NET Framework documentation.

Use PreAuthenticate with Basic Authentication

If you use Basic authentication, the proxy's PreAuthenticate property can be set to true or false. Set it to true to supply specific authentication credentials to cause a WWWauthenticate HTTP header to be passed with the Web request. This prevents the Web server from denying access to 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.

private void ConfigureProxy( WebClientProtocol proxy, 
                             string domain, string username, 
                             string password )
{
  // To improve performance, force pre-authentication
  proxy.PreAuthenticate = true;
  // Set the credentials
  CredentialCache cache = new CredentialCache();
  cache.Add( new Uri(proxy.Url),
             "Negotiate",     
             new NetworkCredential(username, password, domain) );
  proxy.Credentials = cache;
  proxy.ConnectionGroupName = username;
}

Threading

Web Services use ASP.NET thread pooling to process requests. To ensure that your Web Services use the thread pool most effectively, consider the following guidelines:

Tune the thread pool using the Formula for Reducing Contention.
Consider minIoThreads and minWorkerThreads for intermittent burst load.

Tune the Thread Pool by Using the Formula for Reducing Contention

The Formula for Reducing Contention can give you a good starting point for tuning the ASP.NET thread pool. Consider using the Microsoft product group recommended settings (shown in Table 10.2) if you have available CPU, your application performs I/O bound operations (such as calling a Web method or accessing the file system), and you have queued requests as indicated by the ASP.NET Applications/Requests in Application Queue performance counter.

Table 10.2: Recommended Threading Settings for Reducing Contention

Configuration setting	Default (.NET 1.1)	Recommended value
maxconnection	2	12 * #CPUs
maxIoThreads	20	100
maxWorkerThreads	20	100
minFreeThreads	8	88 * #CPUs
minLocalRequestFreeThreads	4	76 * #CPUs

To address this issue, you need to configure the following items in Machine.config. The changes described in the following list should be applied across the settings and not in isolation. For a detailed description of each of these settings, see "Thread Pool Attributes" in Chapter 17, "Tuning .NET Application Performance."

Set maxconnection to 12 * # of CPUs. This setting controls the maximum number of outgoing HTTP connections allowed by the client, which in this case is ASP.NET. The recommendation is to set this to 12 times the number of CPUs.
Set maxIoThreads to 100. This setting controls the maximum number of I/0 threads in the common language runtime (CLR) thread pool. This number is then automatically multiplied by the number of available CPUs. The recommendation is to set this to 100.
Set maxWorkerThreads to 100. This setting controls the maximum number of worker threads in the CLR thread pool. This number is then automatically multiplied by the number of available CPUs. The recommendation is to set this to 100.
Set minFreeThreads to 88 * # of CPUs. The worker process uses this setting to queue up all the incoming requests if the number of available threads in the thread pool falls below the value for this setting. This setting effectively limits the number of concurrently executing requests to maxWorkerThreads – minFreeThreads. The recommendation is to set this to 88 times the number of CPUs. This limits the number of concurrent requests to 12 (assuming maxWorkerThreads is 100).
Set minLocalRequestFreeThreads to 76 * # of CPUs. This worker process uses this setting to queue up requests from localhost (where a Web application calls a Web service on the same server) if the number of available threads in the thread pool falls below this number. This setting is similar to minFreeThreads, but it only applies to requests that use localhost. The recommendation is to set this to 76 times the number of CPUs.

Note The above recommendations are starting points rather than strict rules. You should perform appropriate testing to determine the correct settings for your environment.

If the formula has worked, you should see improved throughput and less idle CPU time:

CPU utilization should go up.
Throughput should increase (ASP.NET Applications/Requests/Sec should go up),
Requests in the application queue (ASP.NET Applications/Requests in Application Queue) should go down.

If this does not improve your performance, you may have a CPU-bound situation. If this is the case, by adding more threads you increase thread context switching. For more information, see "ASP.NET Tuning" in Chapter 17, "Tuning .NET Application Performance."

More Information

For more information, see Microsoft Knowledge Base article 821268, "PRB: Contention, Poor Performance, and Deadlocks When You Make Web Service Requests from ASP.NET Applications," at http://support.microsoft.com/default.aspx?scid=kb;en-us;821268.

Consider minIoThreads and minWorkerThreads for Intermittent Burst Load

If you have burst load scenarios that are intermittent and short (0 to 10 minutes), then the thread pool may not have enough time to reach the optimal level of threads. The use of minIoThreads and minWorkerThreads allows you to configure a minimum number of worker and I/O threads for load conditions.

At the time of this writing, you need a supported fix to configure the settings. For more information, see the following Microsoft Knowledge Base articles:

810259, "FIX: SetMinThreads and GetMinThreads API Added to Common Language Runtime ThreadPool Class," at http://support.microsoft.com/default.aspx?scid=kb;en-us;810259.
827419, "PRB: Sudden Requirement for a Larger Number of Threads from the ThreadPool Class May Result in Slow Computer Response Time," at http://support.microsoft.com/default.aspx?scid=kb;en-us;827419.

More Information

For more information about threading and Web services, see:

"ASP.NET Tuning" in Chapter 17, "Tuning .NET Application Performance"
Microsoft Knowledge Base article 821268, "PRB: Contention, Poor Performance, and Deadlocks When You Make Web Service Requests from ASP.NET Applications," at http://support.microsoft.com/default.aspx?scid=kb;en-us;821268.

One-Way (Fire-and-Forget) Communication

Consider using the OneWay attribute if you do not require a response. Using the OneWay property of SoapDocumentMethod and SoapRpcMethod in the System.Web.Services.Protocols namespace frees the client immediately instead of forcing it to wait for a response.

For a method to support fire-and-forget invocation, you must decorate it with the OneWay attribute, as shown in the following code snippet.

[SoapDocumentMethod(OneWay=true)]
[WebMethod(Description="Returns control immediately")]
public void SomeMethod() 
{…}

This is useful if the client needs to send a message, but does not expect anything as return values or output parameters. Methods marked as OneWay cannot have output parameters or return values.

Asynchronous Web Methods

You can call a Web service asynchronously regardless of whether or not the Web service has been implemented synchronously or asynchronously. Similarly, you can implement a synchronous or asynchronous Web service, but allow either style of caller. Client-side and server-side asynchronous processing is generally performed to free up the current worker thread to perform additional work in parallel.

The asynchronous implementation of a Web method frees up the worker thread to handle other parallel tasks that can be performed by the Web method. This ensures optimal utilization of the thread pool, resulting in throughput gains.

For normal synchronous operations, the Web services asmx handler uses reflection on the assembly to find out which methods have the WebMethod attribute associated with them. The handler simply calls the appropriate method based on the value of the SOAP-Action HTTP header.

However, the Web services asmx handler treats asynchronous Web methods differently. It looks for methods that adhere to the following rules:

Methods adhere to the asynchronous design pattern:
- There are BeginXXX and EndXXX methods for the actual XXX method that you need to expose.
- The BeginXXX method returns an IAsyncResult interface, takes whatever arguments the Web method needs, and also takes two additional parameters of type AsyncCallback and System.Object, respectively.
- The EndXXX method takes an IAsyncResult as a parameter and returns the return type of your Web method.
Both methods are decorated with the WebMethod attribute.

The Web services asmx handler then exposes the method, as shown in the following code snippet.

[WebMethod]
IAsyncResult  BeginMyProc(…)

[WebMethod]
EndMyProc(…)

//the WSDL will show the method as
MyProc(…)

The Web services asmx handler processes incoming requests for asynchronous methods as follows:

Call the BeginXXX method.
Pass the reference to an internal callback function as a parameter to the BeginXXX method, along with the other in parameters. This frees up the worker thread processing the request, allowing it to handle other incoming requests. The asmx handler holds on to the HttpContext of the request until processing of the request is complete and a response has been sent to the client.
Once the callback is called, call the EndXXX function to complete the processing of the method call and return the response as a SOAP response.
Release the HttpContext for the request.

Consider the following guidelines for asynchronous Web methods:

Use asynchronous Web methods for I/O operations.
Do not use asynchronous Web methods when you depend on worker threads.

Use Asynchronous Web Methods for I/O Operations

Consider using asynchronous Web methods if you perform I/O-bound operations such as:

Accessing streams
File I/O operations
Calling another Web service

The .NET Framework provides the necessary infrastructure to handle these operations asynchronously, and you can return an IAsyncResult interface from these types of operations. The .NET Framework exposes asynchronous methods for I/O-bound operations using the asynchronous design pattern. The libraries that use this pattern have BeginXXX and EndXXX methods.

The following code snippet shows the implementation of an asynchronous Web method calling another Web service.

// The client W/S 
public class AsynchWSToWS
{
  WebServ asyncWs = null;
  public AsynchWSToWS(){
    asyncWs = new WebServ();
  }
  
  [System.Web.Services.WebMethod]
  public IAsyncResult BeginSlowProcedure(int milliseconds,AsyncCallback cb, 
                                         object s){
    // make call to other web service and return the IAsyncResult
    return asyncWs.BeginLengthyCall(milliseconds,cb,s);
  }
  
  [System.Web.Services.WebMethod ]
  public string EndSlowProcedure(IAsyncResult call) {
    return asyncWs.EndLengthyCall(call);
  }
}

// The server W/S
public class WebServ
{
  [WebMethod]
  public string LengthyCall(int milliseconds){
    Thread.Sleep(milliseconds);
    return "Hello World";
  }
}

Asynchronous implementation helps when you want to free up the worker thread instead of waiting on the results to return from a potentially long-running task. For this reason, you should avoid asynchronous implementation whenever your work is CPU bound because you do not have idle CPU to service more threads. In this case, an asynchronous implementation results in increased utilization and thread switching on an already busy processor. This is likely to hurt performance and overall throughput of the processor.

Note You should not use asynchronous Web methods when accessing a database. ADO.NET does not provide asynchronous implementation for handling database calls. Wrapping the operation in a delegate is not an option either because you still block a worker thread.

You should only consider using an asynchronous Web method if you are wrapping an asynchronous operation that hands back an IAsyncResult reference.

Do Not Use Asynchronous Web Methods When You Depend on Worker Threads

You should not implement Web methods when your asynchronous implementation depends upon callbacks or delegates because they use worker threads internally. Although the delegate frees the worker thread processing the request, it uses another worker thread from the process thread pool to execute the method. This is a thread that can be used for processing other incoming requests to the Web service. The result is that you consume a worker thread for the delegate-based operation and you increase context switching.

Alternatively, you can use synchronous Web methods and decrease the minFreeThreads setting so that the worker threads can take requests and execute them directly.

In this scenario, you could block the original worker thread by implementing the Web method to run synchronously. An example of the delegate-based implementation is shown in the following code snippet.

// delegate
public delegate string LengthyProcedureAsyncStub(int milliseconds);

//actual method which is exposed as a web service
[WebMethod]
public string LengthyCall(int milliseconds) { 
  System.Threading.Thread.Sleep(milliseconds);
  return "Hello World";
}

[WebMethod]
public IAsyncResult BeginLengthyCall(int milliseconds,AsyncCallback cb, 
object s) {
  LengthyProcedureAsyncStub stub = new LengthyProcedureAsyncStub(LengthyCall);
 //using delegate for asynchronous implementation   
  return stub.BeginInvoke(milliseconds, cb, null); }

[System.Web.Services.WebMethod]
public string EndLengthyCall(IAsyncResult call) {
  return ms.asyncStub.EndInvoke(call);
}

Asynchronous Invocation

Web services clients can call a Web service either synchronously or asynchronously, independently of the way the Web service is implemented.

For server applications, using asynchronous calls to a remote Web service is a good approach if the Web service client can either free the worker thread to handle other incoming requests or perform additional parallel work before blocking for the results. Generally, Windows Forms client applications call Web services asynchronously to avoid blocking the user interface.

Note The HTTP protocol allows at most two simultaneous outbound calls from one client to one Web service.

The WSDL-generated proxy contains support for both types of invocation. The proxy supports the asynchronous call by exposing BeginXXX and EndXXX methods.

The following guidelines help you decide whether or not calling a Web service asynchronously is appropriate:

Consider calling Web services asynchronously when you have additional parallel work.
Use asynchronous invocation to call multiple unrelated Web services.
Call Web services asynchronously for UI responsiveness.

Consider Calling Web Services Asynchronously When You Have Additional Parallel Work

Asynchronous invocation is the most useful when the client has additional work that it can perform while the Web method executes. Asynchronous calls to Web services result in performance and throughput gains because you free the executing worker thread to do parallel work before it is blocked by the Web services call and waits for the results. This lets you concurrently process any work that is not dependent on the results of the Web services call. The following code snippet shows the approach.

private void Page_Load(object sender, System.EventArgs e) 
{
  serv = new localhost.WebService1();
  IAsyncResult result = serv.BeginLengthyProcedure(5000,null,null);
  // perform some additional processing here before blocking 

  // wait for the asynchronous operation to complete
  result.AsyncWaitHandle.WaitOne();
  string retStr = serv.EndLengthyProcedure(result);
}

Use Asynchronous Invocation to Call Multiple Unrelated Web Services

Consider asynchronous invocation if you need to call multiple Web services that do not depend on each other's results. Asynchronous invocation lets you call the services concurrently. This tends to reduce response time and improve throughput. The following code snippet shows the approach.

private void Page_Load(object sender, System.EventArgs e){
  serv1 = new WebService1();
  serv2 = new WebService2();

  IAsyncResult result1 = serv1.BeginLengthyProcedure(1000,null,null);
  IAsyncResult result2 = serv2.BeginSlowProcedure(1000,null,null);

  //wait for the asynchronous operation to complete
  WaitHandle[] waitHandles = new WaitHandle[2];

  waitHandles[0] = result1.AsyncWaitHandle;
  waitHandles[1] = result2.AsyncWaitHandle;

  WaitHandle.WaitAll(waitHandles);  //depending upon the scenario you can
                                    //choose between WaitAny and WaitAll
  string retStr1 = serv1.EndLengthyProcedure(result1);
  string retStr2 = serv2.EndSlowProcedure(result2);
}

Call Web Services Asynchronously for UI Responsiveness

By calling a Web service asynchronously from a Windows Forms application, you free the main user interface thread. You can also consider displaying a progress bar while the call progresses. This helps improve perceived performance.

However, you need to perform some additional work to resynchronize the results with the user interface thread because the Web service call is handled by a separate thread. You need to call the Invoke method for the control on which you need to display the results.

More Information

For more information, see the MSDN article, "At Your Service: Performance Considerations for Making Web Service Calls from ASPX Pages," at http://msdn.microsoft.com/library/en-us/dnservice/html/service07222003.asp.

Timeouts

It is very common for an ASP.NET application to call a Web service. If your application's Web page times out before the call to the Web service times out, this causes an unmanaged resource leak and a ThreadAbortException. This is because I/O completion threads and sockets are used to service the calls. As a result of the exception, the socket connection to the Web service is not closed and cannot be reused by other outbound requests to the Web service. The I/O thread continues to process the Web service response.

To avoid these issues, set timeouts appropriately as follows:

Set your proxy timeout appropriately.
Set your ASP.NET timeout greater than your Web service timeout.
Abort connections for ASP.NET pages that timeout before a Web services call completes.
Consider the responseDeadlockInterval attribute.

Set Your Proxy Timeout Appropriately

When you call a Web service synchronously, set the Timeout property of the Web service proxy. The default value is 100 seconds. You can programmatically set the value before making the call, as shown in the following code snippet.

MyWebServ obj = new MyWebServ();
obj.Timeout = 15000; // in milliseconds

For ASP.NET applications, the Timeout property value should always be less than the executionTimeout attribute of the httpRuntime element in Machine.config. The default value of executionTimeout is 90 seconds. This property determines the time ASP.NET continues to process the request before it returns a timed out error. The value of executionTimeout should be the proxy Timeout, plus processing time for the page, plus buffer time for queues.

Consider reducing the Proxy Timeout value from its default of 100 seconds if you do not expect clients to wait for such a long time. You should do this even under high load conditions when the outbound requests to the Web service could be queued on the Web server. As a second step, reduce the executionTimeout also.
You might need to increase the value if you expect the synchronous call to take more time than the default value before completing the operation. If you send or receive large files, you may need to increase the attribute value. As a second step, increase the executionTimeout attribute to an appropriate value.

Set Your ASP.NET Timeout Greater Than Your Web Service Timeout

The Web service timeout needs to be handled differently, depending upon whether you call the Web service synchronously or asynchronously. In either case, you should ensure that the timeouts are set to a value less than the executionTimeout attribute of the httpRuntime element in Machine.config. The following approaches describe the options for setting the timeouts appropriately:

Synchronous calls to a Web service. Set the proxy Timeout to an appropriate value, as shown in the following code snippet.

MyWebServ obj = new MyWebServ();
obj.Timeout = 15000; // in milliseconds

You can also set the value in the proxy class generated by the WSDL for the Web service. You can set it in the class constructor, as shown in the following code snippet.

public MyWebServ() {
    this.Url = "http://someMachine/mywebserv/myserv.asmx";
    this.Timeout = 10000;  //10 seconds
}

Or you can set it at the method level for a long-running call.

public string LengthyProc(int sleepTime) {
  this.Timeout = 10000; //10 seconds
  object[] results = this.Invoke("LengthyProc", new object[] {sleepTime});
  return ((string)(results[0]));  
}

Asynchronous calls to a Web service. In this case, you should decide on the number of seconds you can wait for the Web service call to return the results. When using a WaitHandle, you can pass the number of milliseconds the executing thread is blocked on the WaitHandle before it aborts the request to the Web service. This is shown in the following code snippet.

MyWebServ obj = new MyWebServ();
IAsyncResult ar = obj.BeginFunCall(5,5,null,null);

// wait for not more than 2 seconds
ar.AsyncWaitHandle.WaitOne(2000,false);
if (!ar.IsCompleted) //if the request is not completed  { 
  WebClientAsyncResult wcar = (WebClientAsyncResult)ar;
  wcar.Abort();//abort the call to web service 
}
else
{ //continue processing the results from web service }

Abort Connections for ASP.NET Pages That Timeout Before a Web Services Call Completes

After you make the configuration changes described in the previous section, if your Web pages time out while Web services calls are in progress, you need to ensure that you abort the Web services calls. This ensures that the underlying connections for the Web services calls are destroyed.

To abort a Web services call, you need a reference to the WebRequest object used to make the Web services call. You can obtain this by overriding the GetWebRequest method in your proxy class and assigning it to a private member of the class before returning the WebRequest. This approach is shown in the following code snippet.

private WebRequest _request;
protected override WebRequest GetWebRequest(Uri uri){
  _request = base.GetWebRequest(uri);
  return _request;
}

Then, in the method that invokes the Web service, you should implement a finally block that aborts the request if a ThreadAbortException is thrown.

[System.Web.Services.Protocols.SoapDocumentMethodAttribute(…)]
public string GoToSleep(int sleepTime) {
  bool timeout = true;
  try {
    object[] results = this.Invoke("GoToSleep", new object[] {sleepTime});
    timeout = false;
    return ((string)(results[0]));  
  } 
  finally {
    if(timeout && _request!=null)
      _request.Abort();
  }
}

Note Modifying generated proxy code is not recommended because the changes are lost as soon as the proxy is regenerated. Instead, derive from the proxy class and implement new functionality in the subclass whenever possible.

Consider the responseDeadlockInterval Attribute

When you make Web services calls from an ASP.NET application, if you are increasing the value of both the proxy timeout and the executionTimeout to greater than 180 seconds, consider changing the responseDeadlockInterval attribute for the processModel element in the Machine.config file. The default value of this attribute is 180 seconds. If there is no response for an executing request for 180 seconds, the ASP.NET worker process will recycle.

You must reconsider your design if it warrants changing the attributes to a higher value.

WebMethods

You add the WebMethod attribute to those public methods in your Web services .asmx file that you want to be exposed to remote clients. Consider the following Web method guidelines:

Prefer primitive parameter types. When you define your Web method, try to use primitive types for the parameters. Using primitive types means that you benefit from reduced serialization, in addition to automatic validation by the .NET Framework.
Consider buffering. By default, the BufferResponse configuration setting is set to true, to ensure that the response is completely buffered before returning to the client. This default setting is good for small amounts of data. For large amounts of data, consider disabling buffering, as shown in the following code snippet.
```
[WebMethod(BufferResponse=false)]
public string GetTextFile() {
  // return large amount of data
}
```
To determine whether or not to enable or disable buffering for your application, measure performance with and without buffering.
Consider caching responses. For applications that deal with relatively static data, consider caching the responses to avoid accessing the database for every client request. You can use the CacheDuration attribute to specify the number of seconds the response should be cached in server memory, as shown in the following code snippet.
```
[WebMethod(CacheDuration=60)]
public string GetSomeDetails() {
  // return large amount of data
}
```
Note that because caching consumes server memory, it might not be appropriate if your Web method returns large amounts of data or data that frequently changes
Enable session state only for Web methods that need it. Session state is disabled by default. If your Web service needs to maintain state, then you can set the EnableSession attribute to true for a specific Web method, as shown in the following code snippet.
```
[WebMethod(EnableSession=true)]
public string GetSomeDetails() {
  // return large amount of data
}
```
Note that clients must also maintain an HTTP cookie to identify the state between successive calls to the Web method.

For more information, see "WebMethodAttribute.EnableSession Property" on MSDN at http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemWebServicesWebMethodAttributeClassEnableSessionTopic.asp.

Serialization

The amount of serialization that is required for your Web method requests and responses is a significant factor for overall Web services performance. Serialization overhead affects network congestion, memory consumption, and processor utilization. To help keep the serialization overhead to a minimum:

Reduce serialization with XmlIgnore.
Reduce round trips.
Consider XML compression.

Reduce Serialization with XmlIgnore

To limit which fields of an object are serialized when you pass the object to or from a Web method and to reduce the amount of data sent over the wire, use the XmlIgnore attribute as shown in the following code snippet. The XmlSerializer class ignores any field annotated with this attribute.

Note Unlike the formatters derived from the IFormatter interface, XmlSerializer serializes only public members.

// 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;
}

Reduce Round Trips

Reducing round trips to a Web service reduces the number of times that messages need to cross serialization boundaries. This helps reduce the overall serialization cost incurred. Design options that help to reduce round trips include the following:

Use message-based interaction with a message-based programming model, rather than an RPC style that requires multiple object interactions to complete a single logical unit of work.
In some cases, split a large payload into multiple calls to the Web service. Consider making the calls in parallel using asynchronous invocation instead of in series. This does not technically reduce the total number of round trips, but in essence the client waits for only a single round trip.

Consider XML Compression

Compressing the XML payload sent over the wire helps reduce the network traffic significantly. You can implement XML compression by using one of the following techniques:

Use SOAP extensions on the server and client for the compression and decompression of requests and responses.
Use a custom HTTP module on the server and override the proxy for the Web service on the client.
Use HTTP compression features available in IIS 5.0 and later versions for compressing the response from the Web services. Note that you need a decompression mechanism on the client.

More Information

For more information about serialization, see:

"XmlSerializer Architecture" in the November 2001 edition of MSDN magazine, at http://msdn.microsoft.com/msdnmag/issues/01/11/webserv/default.aspx.
Microsoft Knowledge Base article 314150, "INFO: Roadmap for XML Serialization in the .NET Framework," at http://support.microsoft.com/default.aspx?scid=kb;en-us;314150.
Microsoft Knowledge Base article 313651, "INFO: Roadmap for XML in the .NET Framework," at http://support.microsoft.com/default.aspx?scid=kb;en-us;313651.
Microsoft Knowledge Base article 317463, "HOW TO: Validate XML Fragments Against an XML Schema in Visual Basic .NET," at http://support.microsoft.com/default.aspx?scid=kb;en-us;317463.

Caching

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

Consider output caching for less volatile data.
Consider providing cache-related information to clients.
Consider perimeter caching.

Consider Output Caching for Less Volatile Data

If portions of your output are static or nearly static, use ASP.NET output caching. To use ASP.NET output caching with Web services, configure the CacheDuration property of the WebMethod attribute. The following code snippet shows the cache duration set to 30 seconds.

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

For more information, see Microsoft Knowledge Base article 318299, "HOW TO: Perform Output Caching with Web Services in Visual C# .NET," at http://support.microsoft.com/default.aspx?scid=kb;en-us;318299.

Consider Providing Cache-Related Information to Clients

Web services clients can implement custom caching solutions to cache the response from Web services. If you intend that clients of your Web services should cache responses, 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. You can add an additional field in the Web service response that specifies the cache expiration time.

Consider Perimeter Caching

If the output from your Web services changes infrequently, use hardware or software to cache the response at the perimeter network. For example, consider ISA firewall-based caching. Perimeter caching means that a response is returned before the request even reaches the Web server, which reduces the number of requests that need to be serviced.

For more information about ISA caching, see the white paper, "Scale-Out Caching with ISA," at http://www.microsoft.com/isaserver/techinfo/deployment/ScaleOutCachingwithISA.asp.

State Management

Web services state can be specific to a user or to an application. Web services use ASP.NET session state to manage per-user data and application state to manage application-wide data. You access session state from a Web service in the same way you do from an ASP.NET application — by using the Session object or System.Web.HttpContext.Current. You access application state using the Application object, and the System.Web.HttpApplicationState class provides the functionality.

Maintaining session state has an impact on concurrency. If you keep data in session state, Web services calls made by one client are serialized by the ASP.NET runtime. Two concurrent requests from the same client are queued up on the same thread in the Web service — the second request waits until the first request is processed. If you do not use session data in a Web method, you should disable sessions for that method.

Maintaining state also affects scalability. First, keeping per-client state in-process or in a state service consumes memory and limits the number of clients your Web service can serve. Second, maintaining in-process state limits your options because in-process state is not shared by servers in a Web farm.

If your Web service needs to maintain state between client requests, you need to choose a design strategy that offers optimum performance and at the same time does not adversely affect the ability of your Web service to scale. The following guidelines help you to ensure efficient state management:

Use session state only where it is needed.
Avoid server affinity.

Use Session State Only Where It Is Needed

To maintain state between requests, you can use session state in your Web services by setting the EnableSession property of the WebMethod attribute to true, as shown in the following code snippet. By default, session state is disabled.

[WebMethod(EnableSession=true)]
YourWebMethod() { ... }

Since you can enable session state at the Web method level, apply this attribute only to those Web methods that need it.

Note Enabling session state pins each session to one thread (to protect session data). Concurrent calls from the same session are serialized once they reach the server, so they have to wait for each other, regardless of the number of CPUs.

Avoid Server Affinity

If you do use session state, in-process session state offers the best performance, but it prevents you from scaling out your solution and operating your Web services in a Web farm. If you need to scale out your Web services, use a remote session state store that can be accessed by all Web servers in the farm.

Bulk Data Transfer

You have the following basic options for passing large amounts of data including binary data to and from Web methods:

Using a byte array Web method parameter.
Returning a URL from the Web service.
Using streaming.

Using a Byte Array Web Method Parameter

With this approach, you pass a byte array as a method parameter. An additional parameter typically specifies the transfer data size. This is the easiest approach, and it supports cross-platform interoperability. However, it has the following issues:

If a failure occurs midway through the transfer, you need to start again from the beginning.
If the client passes an arbitrary amount of data that exceeds your design limitations, you run the risk of running out of memory or exceeding your CPU thresholds on the server. Your Web service is also susceptible to denial of service attacks.

Note that you can limit the maximum SOAP message size for a Web service by using the maxRequestLength setting in the <httpRuntime> section of the Web.config file. In the following example, the limit is set to 8 KB.

<configuration>
  <system.web>
    <httpRuntime maxRequestLength="8096"
        useFullyQualifiedRedirectUrl="true"
        executionTimeout="45"/>
  </system.web>
</configuration>

Base 64 Encoding

For binary data transfer, you can use Base 64 to encode the data. Base 64 encoding is suitable for cross-platform interoperability if your Web service has a heterogeneous client audience.

This approach is more suitable if your data isn't large and the encoding/decoding overhead and size of the payload are not of significant concern. For large-sized data, you can implement a WSE filter and various compression tools to compress the message before sending it over the wire.

For more information about Base 64 encoding and decoding, see:

Microsoft Knowledge Base article 191239, "Sample Base 64 Encoding and Decoding," at http://support.microsoft.com/default.aspx?scid=kb;EN-US;q191239.
MSDN article, "Web Methods Make It Easy to Publish Your App's Interface over the Internet" by Paula Paul, at http://msdn.microsoft.com/msdnmag/issues/02/03/WebMethods/.

Returning a URL from the Web Service

Returning a URL from the Web service is the preferred option for large file downloads. With this approach, you return a URL to the client, and the client then uses HTTP to download the file.

You can consider using the Background Intelligent Transfer Service (BITS), a Windows service, for this purpose. For more information about BITS, see the MSDN article, "Write Auto-Updating Apps with .NET and the Background Intelligent Transfer Service API" by Jason Clark, at http://msdn.microsoft.com/msdnmag/issues/03/02/BITS/.

If you need to use BITS for your .NET application for uploading and downloading of files, you can use the Updater Application Block. For more information, see the MSDN article "Updater Application Block for .NET" at http://msdn.microsoft.com/library/en-us/dnbda/html/updater.asp.

Although returning a URL works for downloads, it is of limited use for uploads. For uploads, you must call the Web service from an HTTP server on the Internet, or the Web service will be unable to resolve the supplied URL.

Using Streaming

If you need to transfer large amounts of data (several megabytes, for example) from a Web method, consider using streaming. If you use streaming, you do not need to buffer all of the data in memory on the client or server. In addition, streaming allows you to send progress updates from a long-running Web service operation to a client that is blocked waiting for the operation to return.

In most cases, data is buffered on both the server and client. On the server side, serialization begins after the Web method has returned, which means that all of the data is usually buffered in the return value object. On the client side, the deserialization of the entire response occurs before the returned object is handed back to the client application, again buffering data in memory.

You can stream data from a Web service in two ways:

Implementing IList
Implementing IXmlSerializable

Implementing IList

The XmlSerializer has special support for types that implement IList whereby it obtains and serializes one list item at a time. To benefit from this streaming behavior, you can implement IList on your return type, and stream out the data one list item at a time without first buffering it.

While this approach provides streaming and the ability to send progress updates, it forces you to work with types that implement IList and to break data down into list items.

Note The serializer is still responsible for serializing and deserializing each individual list item.

Another disadvantage is that the progress is reported from the returned type. This means that the instance of your type that implements IList used on the client side must be able to communicate progress to the client application while the serializer calls IList.Add. While this is achievable, it is not ideal.

The following server and client code samples show how to implement this approach. The server code is shown below.

// Server code
// If the server wants to return progress information, the IList 
indexer would 
// have to know the current progress and return a value indicating that 
progress 
// when it is called.
public class MyList : IList
{
  int progress=0;
  public object this[int index]
  {
    get
    {
      // Pretend to do something that takes .5 seconds
      System.Threading.Thread.Sleep(500);
      if (progress <= 90)
        return progress+=10;
      else
        return "Some data goes here";
    }
    set
    {
      // TODO:  Add setter implementation
    }
  }
   ... other members omitted
}

[WebMethod]
public MyList DoLongOperation()
{
  // To prevent ASP.NET from buffering the response, the WebMethod must set 
  // the BufferOutput property to false
  HttpContext.Current.Response.BufferOutput=false;

  return new MyList();
}

By using the above code, the Web service response is streamed out and consists of 10 progress data points (10 to 100), followed by a string of data.

The corresponding method on the client proxy class must return a type that implements IList. This type must know how to stream items as they are added to the list, and, if required, how to report progress information as it is retrieved from the stream. The relevant MyList member on the client is the Add method:

Note With .NET Framework 1.1 you must manually edit the generated proxy code because Wsdl.exe and the Add Web Reference option in Visual Studio.NET generate a proxy class with a method that returns an object array. You need to modify this to return a type that implements IList.

The client code is shown below.

// Client code
public class MyList : IList
{
  public int Add(object value)
  {
    if (progress < 100)
    {
      progress = Convert.ToInt32(value);
      Console.WriteLine("Progress is {0}",progress);
    }
    else
    {
      Console.WriteLine("Received data: {0}",value);
    }
    return 0;
  }
}

The client's proxy class then contains a method that returns MyList as 
shown below:

public ProgressTestClient.MyList DoLongOperation() 
{ 
  ... code omitted 
}

Implementing IXmlSerializable

Another possible approach is to create a type that implements IXmlSerializable, and return an instance of this type from your Web method and the client proxy's method. This gives you full control of the streaming process. On the server side, the IXmlSerializable type uses the WriteXml method to stream data out:

This solution is slightly cleaner than the previous approach because it removes the arbitrary restriction that the returned type must implement IList. However, the programming model is still a bit awkward because progress must be reported from the returned type. Once again, in.NET Framework 1.1, you must also modify the generated proxy code to set the correct method return type.

The following code sample shows how to implement this approach.

public class ProgressTest : IXmlSerializable
{
  public void WriteXml(System.Xml.XmlWriter writer)
  {
    int progress=0;
    while(progress <= 100)
    {
      writer.WriteElementString("Progress",
                                "http://progresstest.com", 
progress.ToString());
      writer.Flush();
      progress += 10;
      // Pretend to do something that takes 0.5 second
      System.Threading.Thread.Sleep(500);
    }
    writer.WriteElementString("TheData",
                               "http://progresstest.com","Some data 
goes here");
  }
}

The Web method must disable response buffering and return an instance of the ProgressTest type, as shown below.

[WebMethod]
public ProgressTest DoLongOperation2()
{
  HttpContext.Current.Response.BufferOutput=false;
  return new ProgressTest();
}

More Information

For more information about bulk data transfer, see:

Microsoft Knowledge Base article 318425, "HOW TO: Send and Receive Binary Documents by Using an ASP.NET Web Service and Visual C# .NET," at http://support.microsoft.com/default.aspx?scid=kb;en-us;318425.
MSDN article, "Large Data Strategies," at http://msdn.microsoft.com/library/en-us/dnservice/html/service11072001.asp.
MSDN article, "XML,SOAP, and Binary Data," at http://msdn.microsoft.com/library/en-us/dnwebsrv/html/infoset_whitepaper.asp.

Attachments

You have various options when handling attachments with Web services. When choosing your option, consider the following:

WS-Attachments. WSE versions 1.0 and 2.0 provide support for WS-Attachments, which uses Direct Internet Message Encapsulation (DIME) as an encoding format. Although DIME is a supported part of WSE, Microsoft is not investing in this approach long term. DIME is limited because the attachments are outside the SOAP envelope.
Base 64 encoding. Use Base 64 encoding. At this time, you should use Base 64 encoding rather than WS-Attachments when you have advanced Web service requirements, such as security. Base 64 encoding results in a larger message payload (up to two times that of WS-Attachments). You can implement a WSE filter to compress the message with tools such as GZIP before sending it over the network for large amounts of binary data. If you cannot afford the message size that Base 64 introduces and you can rely on the transport for security (for example, you rely on SSL or IPSec), then consider the WSE WS-Attachments implementation. Securing the message is preferable to securing the transport so that messages can be routed securely, whereas transport only addresses point-to-point communication.
SOAP Message Transmission Optimization Mechanism (MTOM). MTOM, which is a derivative work of SOAP messages with attachments (SwA), is likely to be the future interop technology. MTOM is being standardized by the World Wide Web Consortium (W3C) and is much more composition-friendly than SwA.

SOAP Messages with Attachments (SwA)

SwA (also known as WS-I Attachments Profile 1.0) is not supported. This is because you cannot model a MIME message as an XML Infoset, which introduces a non-SOAP processing model and makes it difficult to compose SwA with the rest of the WS-* protocols, including WS-Security. The W3C MTOM work was specifically chartered to fix this problem with SwA, and Microsoft is planning to support MTOM in WSE 3.0.

COM Interop

Calling single-threaded apartment (STA) objects from Web services is neither tested nor supported. The ASPCOMPAT attribute that you would normally use in ASP.NET pages when calling Apartment threaded objects is not supported in Web services.

More Information

For more information, see Microsoft Knowledge Base article 303375, "INFO: XML Web Services and Apartment Objects," at http://support.microsoft.com/default.aspx?scid=kb;en-us;303375.

Measuring and Analyzing Web Services Performance

The quickest way to measure the performance of a Web services call is to use the Microsoft Win32® QueryPerformanceCounter API, which can be used with QueryPerformanceFrequency to determine the precise number of seconds that the call consumed.

Note You can also use the ASP.NET/Request Execution Time performance counter on the server hosting the Web service.

More Information

For more information, see "How To: Time Managed Code Using QueryPerformanceCounter and QueryPerformanceFrequency" in the "How To" section of this guide.
For more information about measuring Web services performance, see "Web Services" in Chapter 15, "Measuring .NET Application Performance"

Web Service Enhancements

Web Service Enhancements (WSE) is an implementation provided to support emerging Web services standards. This section briefly explains WSE, its role in Web services, and sources of additional information.

WSE 2.0 provides a set of classes implemented in the Microsoft.Web.Services.dll to support the following Web services standards:

WS-Security
WS-SecureConversation
WS-Trust
WS-Policy
WS-Addressing
WS-Referrals
WS-Attachments

Figure 10.2 shows how WSE extends the .NET Framework to provide this functionality.

Figure 10.2: WSE runtime

The WSE runtime consists of a pipeline of filters that intercepts inbound SOAP requests and outgoing SOAP response messages. WSE provides a programming model to manage the SOAP headers and messages using the SoapContext class. This gives you the ability to implement various specifications that it supports.

More Information

For more information about WSE, see the MSDN article, "Web Services Enhancements (WSE)," at http://msdn.microsoft.com/webservices/building/wse/default.aspx.

Summary

Web services are the recommended communication mechanism for distributed .NET applications. It is likely that large portions of your application are depending on them or will depend on them. For this reason, it is essential that you spend time optimizing Web services performance and that you design and implement your Web services with knowledge of the important factors that affect their performance and scalability.

This chapter has presented the primary Web services performance and scalability issues that you must address. It has also provided a series of implementation techniques that enable you to tackle these issues and build highly efficient Web services solutions.

Additional Resources

For more information, see the following resources:

For a printable checklist, see "Checklist: Web Services Performance" in the "Checklists" section of this guide.
Chapter 4, "Architecture and Design Review of a .NET Application for Performance and Scalability"
Chapter 13, "Code Review: .NET Application Performance" See the "Web Services" and "ASP.NET" sections.
Chapter 15, "Measuring .NET Application Performance" See the "Web Services" and "ASP.NET" sections.
Chapter 16, "Testing .NET Application Performance"
Chapter 17, "Tuning .NET Application Performance" See the "Web Services Tuning" and "ASP.NET Tuning" sections.
For key recommendations to help you create high-performance .NET Enterprise Services components, see ".NET Enterprise Services Performance" by Richard Turner, on MSDN at http://msdn.microsoft.com/library/en-us/dncomser/html/entsvcperf.asp.
For more information on using Microsoft WSE, see Microsoft Knowledge Base article 821377, "Support WebCast: Introduction to Microsoft Web Services Enhancements," at http://support.microsoft.com/default.aspx?scid=kb;en-us;821377.

你可能感兴趣的:(Improving Web Services Performance)

理解Gunicorn：Python WSGI服务器的基石范范0825 ipython linux 运维
理解Gunicorn：PythonWSGI服务器的基石介绍Gunicorn，全称GreenUnicorn，是一个为PythonWSGI（WebServerGatewayInterface）应用设计的高效、轻量级HTTP服务器。作为PythonWeb应用部署的常用工具，Gunicorn以其高性能和易用性著称。本文将介绍Gunicorn的基本概念、安装和配置，帮助初学者快速上手。1.什么是Gunico
Google earth studio 简介陟彼高冈yu 旅游
GoogleEarthStudio是一个基于Web的动画工具，专为创作使用GoogleEarth数据的动画和视频而设计。它利用了GoogleEarth强大的三维地图和卫星影像数据库，使用户能够轻松地创建逼真的地球动画、航拍视频和动态地图可视化。网址为https://www.google.com/earth/studio/。GoogleEarthStudio是一个基于Web的动画工具，专为创作使用G
PHP环境搭建详细教程好看资源平台前端 php
PHP是一个流行的服务器端脚本语言，广泛用于Web开发。为了使PHP能够在本地或服务器上运行，我们需要搭建一个合适的PHP环境。本教程将结合最新资料，介绍在不同操作系统上搭建PHP开发环境的多种方法，包括Windows、macOS和Linux系统的安装步骤，以及本地和Docker环境的配置。1.PHP环境搭建概述PHP环境的搭建主要分为以下几类：集成开发环境：例如XAMPP、WAMP、MAMP，这
DIV+CSS+JavaScript技术制作网页（旅游主题网页设计与制作）云南大理 STU学生网页设计网页设计期末网页作业 html静态网页 html5期末大作业网页设计 web大作业
️精彩专栏推荐作者主页:【进入主页—获取更多源码】web前端期末大作业：【HTML5网页期末作业(1000套)】程序员有趣的告白方式：【HTML七夕情人节表白网页制作(110套)】文章目录二、网站介绍三、网站效果▶️1.视频演示2.图片演示四、网站代码HTML结构代码CSS样式代码五、更多源码二、网站介绍网站布局方面：计划采用目前主流的、能兼容各大主流浏览器、显示效果稳定的浮动网页布局结构。网站程
关于城市旅游的HTML网页设计——(旅游风景云南 5页)HTML+CSS+JavaScript 二挡起步 web前端期末大作业 javascript html css 旅游风景
⛵源码获取文末联系✈Web前端开发技术描述网页设计题材，DIV+CSS布局制作,HTML+CSS网页设计期末课程大作业|游景点介绍|旅游风景区|家乡介绍|等网站的设计与制作|HTML期末大学生网页设计作业，Web大学生网页HTML：结构CSS：样式在操作方面上运用了html5和css3，采用了div+css结构、表单、超链接、浮动、绝对定位、相对定位、字体样式、引用视频等基础知识JavaScrip
HTML网页设计制作大作业（div+css）云南我的家乡旅游景点带文字滚动二挡起步 web前端期末大作业 web设计网页规划与设计 html css javascript dreamweaver 前端
Web前端开发技术描述网页设计题材，DIV+CSS布局制作,HTML+CSS网页设计期末课程大作业游景点介绍|旅游风景区|家乡介绍|等网站的设计与制作HTML期末大学生网页设计作业HTML：结构CSS：样式在操作方面上运用了html5和css3，采用了div+css结构、表单、超链接、浮动、绝对定位、相对定位、字体样式、引用视频等基础知识JavaScript：做与用户的交互行为文章目录前端学习路线
git - Webhook让部署自动化大猪大猪
我们现在有一个需求，将项目打包上传到gitlab或者github后，程序能自动部署，不用手动地去服务器中进行项目更新并运行，如何做到？这里我们可以使用gitlab与github的挂钩，挂钩的原理就是，每当我们有请求到gitlab与github服务器时，这时他俩会根据我们配置的挂钩地扯进行访问，webhook挂钩程序会一直监听着某个端口请求，一但收到他们发过来的请求，这时就知道用户有请求提交了，这时
webpack图片等资源的处理 dmengmeng
需要的loaderfile-loader（让我们可以引入这些资源文件）url-loader（其实是file-loader的二次封装）img-loader（处理图片所需要的）在没有使用任何处理图片的loader之前，比如说css中用到了背景图片，那么最后打包会报错的，因为他没办法处理图片。其实你只想能够使用图片的话。只加一个file-loader就可以，打开网页能准确看到图片。{test:/\.(p
「豆包Marscode体验官」 | 云端 IDE 启动 & Rust 体验张风捷特烈 ide rust 开发语言后端
theme:cyanosis我正在参加「豆包MarsCode初体验」征文活动MarsCode可以看作一个运行在服务端的远程VSCode开发环境。对于我这种想要学习体验某些语言，但不想在电脑里装环境的人来说非常友好。本文就来介绍一下在MarsCode里，我的体验rust开发体验。一、MarsCode是什么它的本质是:提供代码助手和云端IDE服务的web网站，可通过下面的链接访问https://www
Python神器！WEB自动化测试集成工具 DrissionPage 亚丁号 python 开发语言
一、前言用requests做数据采集面对要登录的网站时，要分析数据包、JS源码，构造复杂的请求，往往还要应付验证码、JS混淆、签名参数等反爬手段，门槛较高。若数据是由JS计算生成的，还须重现计算过程，体验不好，开发效率不高。使用浏览器，可以很大程度上绕过这些坑，但浏览器运行效率不高。因此，这个库设计初衷，是将它们合而为一，能够在不同须要时切换相应模式，并提供一种人性化的使用方法，提高开发和运行效率
Java爬虫框架（一）--架构设计狼图腾-狼之传说 java 框架 java 任务 html解析器存储电子商务
一、架构图那里搜网络爬虫框架主要针对电子商务网站进行数据爬取，分析，存储，索引。爬虫：爬虫负责爬取，解析，处理电子商务网站的网页的内容数据库：存储商品信息索引：商品的全文搜索索引Task队列：需要爬取的网页列表Visited表：已经爬取过的网页列表爬虫监控平台：web平台可以启动，停止爬虫，管理爬虫，task队列，visited表。二、爬虫1.流程1)Scheduler启动爬虫器，TaskMast
Java：爬虫框架 dingcho Java java 爬虫
一、ApacheNutch2【参考地址】Nutch是一个开源Java实现的搜索引擎。它提供了我们运行自己的搜索引擎所需的全部工具。包括全文搜索和Web爬虫。Nutch致力于让每个人能很容易,同时花费很少就可以配置世界一流的Web搜索引擎.为了完成这一宏伟的目标,Nutch必须能够做到:每个月取几十亿网页为这些网页维护一个索引对索引文件进行每秒上千次的搜索提供高质量的搜索结果简单来说Nutch支持分
MongoDB知识概括 GeorgeLin98 持久层 mongodb
MongoDB知识概括MongoDB相关概念单机部署基本常用命令索引-IndexSpirngDataMongoDB集成副本集分片集群安全认证MongoDB相关概念业务应用场景：传统的关系型数据库（如MySQL），在数据操作的“三高”需求以及应对Web2.0的网站需求面前，显得力不从心。解释：“三高”需求：①Highperformance-对数据库高并发读写的需求。②HugeStorage-对海量数
Python实现下载当前年份的谷歌影像 sand&wich python 开发语言
在GIS项目和地图应用中，获取最新的地理影像数据是非常重要的。本文将介绍如何使用Python代码从Google地图自动下载当前年份的影像数据，并将其保存为高分辨率的TIFF格式文件。这个过程涉及地理坐标转换、多线程下载和图像处理。关键功能该脚本的核心功能包括：坐标转换：支持WGS-84与WebMercator投影之间转换，以及处理中国GCJ-02偏移。自动化下载：多线程下载地图瓦片，提高效率。图像
Spring MVC 全面指南：从入门到精通的详细解析一杯梅子酱技术栈学习 spring mvc java
引言：SpringMVC，作为Spring框架的一个重要模块，为构建Web应用提供了强大的功能和灵活性。无论是初学者还是有一定经验的开发者，掌握SpringMVC都将显著提升你的Web开发技能。本文旨在为初学者提供一个全面且易于理解的学习路径，通过详细的知识点分析和实际案例，帮助你快速上手SpringMVC，让学习过程既深刻又高效。一、SpringMVC简介1.1什么是SpringMVC？Spri
Spring Boot中实现跨域请求 BABA8891 spring boot 后端 java
在SpringBoot中实现跨域请求（CORS，Cross-OriginResourceSharing）可以通过多种方式，以下是几种常见的方法：1.使用@CrossOrigin注解在SpringBoot中，你可以在控制器或者具体的请求处理方法上使用@CrossOrigin注解来允许跨域请求。在控制器上应用：importorg.springframework.web.bind.annotation.
WebMagic：强大的Java爬虫框架解析与实战 Aaron_945 Java java 爬虫开发语言
文章目录引言官网链接WebMagic原理概述基础使用1.添加依赖2.编写PageProcessor高级使用1.自定义Pipeline2.分布式抓取优点结论引言在大数据时代，网络爬虫作为数据收集的重要工具，扮演着不可或缺的角色。Java作为一门广泛使用的编程语言，在爬虫开发领域也有其独特的优势。WebMagic是一个开源的Java爬虫框架，它提供了简单灵活的API，支持多线程、分布式抓取，以及丰富的
00. 这里整理了最全的爬虫框架（Java + Python）有一只柴犬爬虫系列爬虫 java python
目录1、前言2、什么是网络爬虫3、常见的爬虫框架3.1、java框架3.1.1、WebMagic3.1.2、Jsoup3.1.3、HttpClient3.1.4、Crawler4j3.1.5、HtmlUnit3.1.6、Selenium3.2、Python框架3.2.1、Scrapy3.2.2、BeautifulSoup+Requests3.2.3、Selenium3.2.4、PyQuery3.2
最简单将静态网页挂载到服务器上(不用nginx) 全能全知者服务器 nginx 运维前端 html 笔记
最简单将静态网页挂载到服务器上(不用nginx)如果随便弄个静态网页挂在服务器都要用nignx就太麻烦了，所以直接使用Apache来搭建一些简单前端静态网页会相对方便很多检查Web服务器服务状态：sudosystemctlstatushttpd#ApacheWeb服务器如果发现没有安装web服务器：安装Apache：sudoyuminstallhttpd启动Apache：sudosystemctl
uniapp使用内置地图选择插件，实现地址选择并在地图上标点神夜大侠 Uniapp vue.js uniapp
uniapp使用内置地图选择插件，实现地址选择并在地图上标点代码如下：page{background:#F4F5F6;}::-webkit-scrollbar{width:0;height:0;color:transparent;}page{height:100%;width:100%;font-size:24rpx;}image,view,input,textarea,label,text,na
【Golang】实现 Excel 文件下载功能 RumIV Golang golang excel 开发语言
在当今的网络应用开发中，提供数据导出功能是一项常见的需求。Excel作为一种广泛使用的电子表格格式，通常是数据导出的首选格式之一。在本教程中，我们将学习如何使用Go语言和GinWeb框架来创建一个Excel文件，并允许用户通过HTTP请求下载该文件。准备工作在开始之前，请确保您的开发环境中已经安装了Go语言和相关的开发工具。此外，您还需要安装GinWeb框架和excelize包，这两个包都将用于我
VUE3 + xterm + nestjs实现web远程终端或连接开启SSH登录的路由器和交换机。焚木灵 node.js vue
可远程连接系统终端或开启SSH登录的路由器和交换机。相关资料：xtermjs/xterm.js:Aterminalfortheweb(github.com)后端实现(NestJS)：1、安装依赖：npminstallnode-ssh@nestjs/websockets@nestjs/platform-socket.io2、我们将创建一个名为RemoteControlModule的NestJS模块，
metaRTC8.0，一个全新架构的webRTC SDK库 metaRTC webrtc 音视频
概述metaRTC8.0是metaRTC开源以来架构变化最大的一个版本，是metaIPC3.0等高性能的基础。metaRTC8.0是一个全新架构版本，并非在metaRTC7.0版本上简单升级，在QOS/语音对讲/内存占用/视频文件录制读取等方面新增多个模块，在弱网对抗/语音对讲/内存优化等效果上有显著提升。metaRTC8.0在一年多的开发中进行了近200次迭代，metaRTC8.0社区版计划在2
metaRTC/webRTC QOS 方案与实践 metaRTC metaRTC 解决方案 webrtc qos
概述质量服务(QOS/QualityofService)是指利用各种技术方案提高网络通信质量的技术，网络通信质量需要解决下面两个问题：网络问题：UDP/不稳定网络/弱网下的丢包/延时/乱序/抖动数据量问题：发送数据量超带宽负载和平滑发送拥塞控制是各种技术方案的数据基础，丢包恢复解决丢包问题，抗乱序抖动解决网络乱序抖动问题，流量控制解决平滑发送数据/数据超带宽负载/延时问题。拥塞控制(Congest
metaRTC5.0 API编程指南(一) metaRTC metaRTC c++c语言 webrtc
概述metaRTC5.0版本API进行了重构，本篇文章将介绍webrtc传输调用流程和例子。metaRTC5.0版本提供了C++和纯C两种接口。纯C接口YangPeerConnection头文件:include/yangrtc/YangPeerConnection.htypedefstruct{void*conn;YangAVInfo*avinfo;YangStreamConfigstreamco
详解“c:/work/src/components/a/b.vue“‘ has no default export报错原因 hw_happy 开发语言前端 vue.js javascript
前情提要在一个vue文件中需要引入定义的b.vue文件，但是提示b文件没有默认导出，对于vue2文件来说有exportdefault，在中，所有定义的变量、函数和组件都会自动被视为默认导出的组件内容。因此，不需要显式地使用exportdefault来导出组件。但是在我引用这个文件的时候还是提示了这个错误，原来是我的项目使用了ts和vite\webpack，因为TypeScript和Vue的默认导出
原力元宇宙：Web3时代下的虚拟现实融合与普通人逆袭的机遇口碑信息传播者
在数字化浪潮席卷全球的今天，一个崭新的概念——原力元宇宙，正以其独特的魅力吸引着越来越多的目光。作为元宇宙国际性的一个项目，原力元宇宙不仅融合了Web3第三代互联网的前沿技术，更将虚拟现实与现实生活紧密相连，为我们描绘出一幅前所未有的数字新世界画卷。13分钟视频内容讲明白原力元宇宙创富项目，中国区运营服务对接微信：ForceZen原力元宇宙，是一个时代的跨越，它代表着互联网技术的又一次革新。Web
html+css网页设计旅游网站首页1个页面 html+css+js网页设计 html css 旅游
html+css网页设计旅游网站首页1个页面网页作品代码简单，可使用任意HTML辑软件（如：Dreamweaver、HBuilder、Vscode、Sublime、Webstorm、Text、Notepad++等任意html编辑软件进行运行及修改编辑等操作）。获取源码1，访问该网站https://download.csdn.net/download/qq_42431718/897527112，点击
bat+ffmpeg批处理图片，图片批量转码张雨zy 音视频 ffmpeg
直接在cmd中输入//批量转码文件for%ain("*.png")doffmpeg-i"%a"-fs1024k"%~na.webp"//删除所有pngdel*.png@echooff表示执行了这条命令后关闭所有命令(包括本身这条命令)的回显。而echooff命令则表示关闭其他所有命令(不包括本身这条命令)的回显，@的作用就是关闭紧跟其后的一条命令的回显脚本完整代码写入脚本中后，需要多加一个%，例如
css设置当字数超过限制后以省略号（...）显示周bro css 前端 vue css3 html 经验分享
1、文字超出一行，省略超出部分，显示’…’用text-overflow:ellipsis属性来，当然还需要加宽度width属来兼容部分浏览。overflow:hidden;text-overflow:ellipsis;white-space:nowrap;2、多行文本溢出显示省略号display:-webkit-box;-webkit-box-orient:vertical;-webkit-lin
Spring4.1新特性——综述 jinnianshilongnian spring 4.1
目录 Spring4.1新特性——综述 Spring4.1新特性——Spring核心部分及其他 Spring4.1新特性——Spring缓存框架增强 Spring4.1新特性——异步调用和事件机制的异常处理 Spring4.1新特性——数据库集成测试脚本初始化 Spring4.1新特性——Spring MVC增强 Spring4.1新特性——页面自动化测试框架Spring MVC T
Schema与数据类型优化 annan211 数据结构 mysql
目前商城的数据库设计真是一塌糊涂，表堆叠让人不忍直视，无脑的架构师，说了也不听。在数据库设计之初，就应该仔细揣摩可能会有哪些查询，有没有更复杂的查询，而不是仅仅突出很表面的业务需求，这样做会让你的数据库性能成倍提高，当然，丑陋的架构师是不会这样去考虑问题的。选择优化的数据类型 1 更小的通常更好更小的数据类型通常更快，因为他们占用更少的磁盘、内存和cpu缓存，
第一节 HTML概要学习 chenke html Web css
第一节 HTML概要学习 1. 什么是HTML HTML是英文Hyper Text Mark-up Language(超文本标记语言)的缩写，它规定了自己的语法规则，用来表示比“文本”更丰富的意义，比如图片，表格，链接等。浏览器（IE,FireFox等）软件知道HTML语言的语法，可以用来查看HTML文档。目前互联网上的绝大部分网页都是使用HTML编写的。打开记事本输入一下内
MyEclipse里部分习惯的更改 Array_06 eclipse
继续补充中---------------------- 1.更改自己合适快捷键windows-->prefences-->java-->editor-->Content Assist--> Activation triggers for java的右侧“.”就可以改变常用的快捷键选中 Text
近一个月的面试总结 cugfy 面试
本文是在学习中的总结，欢迎转载但请注明出处：http://blog.csdn.net/pistolove/article/details/46753275 前言打算换个工作，近一个月面试了不少的公司，下面将一些面试经验和思考分享给大家。另外校招也快要开始了，为在校的学生提供一些经验供参考，希望都能找到满意的工作。
HTML5一个小迷宫游戏 357029540 html5
通过《HTML5游戏开发》摘抄了一个小迷宫游戏，感觉还不错，可以画画，写字，把摘抄的代码放上来分享下，喜欢的同学可以拿来玩玩！ <html> <head> <title>创建运行迷宫</title> <script type="text/javascript"
10步教你上传githib数据张亚雄 git
官方的教学还有其他博客里教的都是给懂的人说得，对已我们这样对我大菜鸟只能这么来锻炼，下面先不玩什么深奥的，先暂时用着10步干净利索。等玩顺溜了再用其他的方法。操作过程（查看本目录下有哪些文件NO.1）ls （跳转到子目录NO.2）cd+空格+目录（继续NO.3）ls （匹配到子目录NO.4）cd+ 目录首写字母+tab键+（首写字母“直到你所用文件根就不再按TAB键了”）（查看文件
MongoDB常用操作命令大全 adminjun mongodb 操作命令
成功启动MongoDB后，再打开一个命令行窗口输入mongo，就可以进行数据库的一些操作。输入help可以看到基本操作命令，只是MongoDB没有创建数据库的命令，但有类似的命令如：如果你想创建一个“myTest”的数据库，先运行use myTest命令，之后就做一些操作（如：db.createCollection('user')）,这样就可以创建一个名叫“myTest”的数据库。一
bat调用jar包并传入多个参数 aijuans
下面的主程序是通过eclipse写的： 1.在Main函数接收bat文件传递的参数（String[] args）如： String ip =args[0]; String user=args[1]; &nbs
Java中对类的主动引用和被动引用 ayaoxinchao java 主动引用对类的引用被动引用类初始化
在Java代码中，有些类看上去初始化了，但其实没有。例如定义一定长度某一类型的数组，看上去数组中所有的元素已经被初始化，实际上一个都没有。对于类的初始化，虚拟机规范严格规定了只有对该类进行主动引用时，才会触发。而除此之外的所有引用方式称之为对类的被动引用，不会触发类的初始化。虚拟机规范严格地规定了有且仅有四种情况是对类的主动引用，即必须立即对类进行初始化。四种情况如下：1.遇到ne
导出数据库提示 outfile disabled BigBird2012 mysql
在windows控制台下，登陆mysql，备份数据库： mysql>mysqldump -u root -p test test > D:\test.sql 使用命令 mysqldump 格式如下： mysqldump -u root -p *** DBNAME > E:\\test.sql。注意：执行该命令的时候不要进入mysql的控制台再使用，这样会报
Javascript 中的 && 和 || bijian1013 JavaScript &&||
准备两个对象用于下面的讨论 var alice = { name: "alice", toString: function () { return this.name; } } var smith = { name: "smith",
[Zookeeper学习笔记之四]Zookeeper Client Library会话重建 bit1129 zookeeper
为了说明问题，先来看个简单的示例代码： package com.tom.zookeeper.book; import com.tom.Host; import org.apache.zookeeper.WatchedEvent; import org.apache.zookeeper.ZooKeeper; import org.apache.zookeeper.Wat
【Scala十一】Scala核心五：case模式匹配 bit1129 scala
package spark.examples.scala.grammars.caseclasses object CaseClass_Test00 { def simpleMatch(arg: Any) = arg match { case v: Int => "This is an Int" case v: (Int, String)
运维的一些面试题 yuxianhua linux
1、Linux挂载Winodws共享文件夹 mount -t cifs //1.1.1.254/ok /var/tmp/share/ -o username=administrator,password=yourpass 或 mount -t cifs -o username=xxx,password=xxxx //1.1.1.1/a /win
Java lang包-Boolean BrokenDreams boolean
Boolean类是Java中基本类型boolean的包装类。这个类比较简单，直接看源代码吧。 public final class Boolean implements java.io.Serializable,
读《研磨设计模式》-代码笔记-命令模式-Command bylijinnan java 设计模式
声明：本文只为方便我个人查阅和理解，详细的分析以及源代码请移步原作者的博客http://chjavach.iteye.com/ import java.util.ArrayList; import java.util.Collection; import java.util.List; /** * GOF 在《设计模式》一书中阐述命令模式的意图：“将一个请求封装
matlab下GPU编程笔记 cherishLC matlab
不多说，直接上代码 gpuDevice % 查看系统中的gpu,,其中的DeviceSupported会给出matlab支持的GPU个数。 g=gpuDevice(1); %会清空 GPU 1中的所有数据,,将GPU1 设为当前GPU reset(g) %也可以清空GPU中数据。 a=1; a=gpuArray(a); %将a从CPU移到GPU中 onGP
SVN安装过程 crabdave SVN
SVN安装过程 subversion-1.6.12 ./configure --prefix=/usr/local/subversion --with-apxs=/usr/local/apache2/bin/apxs --with-apr=/usr/local/apr --with-apr-util=/usr/local/apr --with-openssl=/
sql　行列转换 daizj sql 行列转换行转列列转行
行转列的思想是通过case when 来实现列转行的思想是通过union all 来实现下面具体例子：假设有张学生成绩表(tb)如下: Name Subject Result 张三语文　　74 张三数学　　83 张三物理　　93 李四语文　　74 李四数学　　84 李四物理　　94 */ /* 想变成姓名 &
MySQL--主从配置 dcj3sjt126com mysql
linux下的mysql主从配置：说明：由于MySQL不同版本之间的(二进制日志)binlog格式可能会不一样，因此最好的搭配组合是Master的MySQL版本和Slave的版本相同或者更低， Master的版本肯定不能高于Slave版本。（版本向下兼容） mysql1 : 192.168.100.1 //master mysq
关于yii 数据库添加新字段之后model类的修改 dcj3sjt126com Model
rules: array('新字段','safe','on'=>'search') 1、array('新字段', 'safe')//这个如果是要用户输入的话，要加一下， 2、array('新字段', 'numerical'),//如果是数字的话 3、array('新字段', 'length', 'max'=>100),//如果是文本 1、2、3适当的最少要加一条，新字段才会被
sublime text3 中文乱码解决 dyy_gusi Sublime Text
sublime text3中文乱码解决原因：缺少转换为UTF-8的插件目的：安装ConvertToUTF8插件包第一步：安装能自动安装插件的插件，百度“Codecs33”，然后按照步骤可以得到以下一段代码： import urllib.request,os,hashlib; h = 'eb2297e1a458f27d836c04bb0cbaf282' + 'd0e7a30980927
概念了解：CGI，FastCGI，PHP-CGI与PHP-FPM geeksun PHP
CGI CGI全称是“公共网关接口”(Common Gateway Interface)，HTTP服务器与你的或其它机器上的程序进行“交谈”的一种工具，其程序须运行在网络服务器上。 CGI可以用任何一种语言编写，只要这种语言具有标准输入、输出和环境变量。如php,perl,tcl等。 FastCGI FastCGI像是一个常驻(long-live)型的CGI，它可以一直执行着，只要激活后，不
Git push 报错 "error: failed to push some refs to " 解决 hongtoushizi git
Git push 报错 "error: failed to push some refs to " . 此问题出现的原因是：由于远程仓库中代码版本与本地不一致冲突导致的。由于我在第一次git pull --rebase 代码后，准备push的时候，有别人往线上又提交了代码。所以出现此问题。解决方案： 1： git pull 2：
第四章 Lua模块开发 jinnianshilongnian nginx lua
在实际开发中，不可能把所有代码写到一个大而全的lua文件中，需要进行分模块开发；而且模块化是高性能Lua应用的关键。使用require第一次导入模块后，所有Nginx 进程全局共享模块的数据和代码，每个Worker进程需要时会得到此模块的一个副本（Copy-On-Write），即模块可以认为是每Worker进程共享而不是每Nginx Server共享；另外注意之前我们使用init_by_lua中初
java.lang.reflect.Proxy liyonghui160com
1.简介 Proxy 提供用于创建动态代理类和实例的静态方法（1）动态代理类的属性代理类是公共的、最终的，而不是抽象的未指定代理类的非限定名称。但是，以字符串 "$Proxy" 开头的类名空间应该为代理类保留代理类扩展 java.lang.reflect.Proxy 代理类会按同一顺序准确地实现其创建时指定的接口
Java中getResourceAsStream的用法 pda158 java
1.Java中的getResourceAsStream有以下几种： 1. Class.getResourceAsStream(String path) ： path 不以’/'开头时默认是从此类所在的包下取资源，以’/'开头则是从ClassPath根下获取。其只是通过path构造一个绝对路径，最终还是由ClassLoader获取资源。　　2. Class.getClassLoader.get
spring 包官方下载地址（非maven） sinnk spring
SPRING官方网站改版后，建议都是通过 Maven和Gradle下载，对不使用Maven和Gradle开发项目的，下载就非常麻烦，下给出Spring Framework jar官方直接下载路径: http://repo.springsource.org/libs-release-local/org/springframework/spring/ s
Oracle学习笔记(7) 开发PLSQL子程序和包 vipbooks oracle sql 编程
哈哈，清明节放假回去了一下，真是太好了，回家的感觉真好啊！现在又开始出差之旅了，又好久没有来了，今天继续Oracle的学习！这是第七章的学习笔记，学习完第六章的动态SQL之后，开始要学习子程序和包的使用了……，希望大家能多给俺一些支持啊！编程时使用的工具是PLSQL

Improving Web Services Performance

Contents

Objectives

Overview

How to Use This Chapter

Architecture

Client-Side Proxy Classes

Prescriptive Guidance for Web Services, Enterprise Services, and .NET Remoting

Object Orientation and Service Orientation

Application Boundaries

Recommendations for Web Services, Enterprise Services, and .NET Remoting

Caveats

More Information

Performance and Scalability Issues

Design Considerations

Design Chunky Interfaces to Reduce Round Trips

Prefer Message-Based Programming Over RPC Style

Use Literal Message Encoding for Parameter Formatting

Prefer Primitive Types for Web Services Parameters

Avoid Maintaining Server State Between Calls

Consider Input Validation for Costly Web Methods

Consider Your Approach to Caching

Consider Approaches for Bulk Data Transfer and Attachments

Avoid Calling Local Web Services

Implementation Considerations

Connections

Configure The maxconnection Attribute

Before Making the Change

Evaluating the Change

Prioritize and Allocate Connections Across Discrete Web Services

Use a Single Identity for Outbound Calls

Consider UnsafeAuthenticatedConnectionSharing with Windows Integrated Authentication

Use PreAuthenticate with Basic Authentication

Threading

Tune the Thread Pool by Using the Formula for Reducing Contention

Consider minIoThreads and minWorkerThreads for Intermittent Burst Load

More Information

One-Way (Fire-and-Forget) Communication

Asynchronous Web Methods

Use Asynchronous Web Methods for I/O Operations

Do Not Use Asynchronous Web Methods When You Depend on Worker Threads

Asynchronous Invocation

Consider Calling Web Services Asynchronously When You Have Additional Parallel Work

Use Asynchronous Invocation to Call Multiple Unrelated Web Services

Call Web Services Asynchronously for UI Responsiveness

Timeouts

Set Your Proxy Timeout Appropriately

Set Your ASP.NET Timeout Greater Than Your Web Service Timeout

Abort Connections for ASP.NET Pages That Timeout Before a Web Services Call Completes

Consider the responseDeadlockInterval Attribute

WebMethods

Serialization

Reduce Serialization with XmlIgnore

Reduce Round Trips

Consider XML Compression

More Information

Caching

Consider Output Caching for Less Volatile Data

Consider Providing Cache-Related Information to Clients

Consider Perimeter Caching

State Management

Use Session State Only Where It Is Needed

Avoid Server Affinity

Bulk Data Transfer

Using a Byte Array Web Method Parameter

Base 64 Encoding

Returning a URL from the Web Service

Using Streaming

Implementing IList

Implementing IXmlSerializable

More Information

Attachments

SOAP Messages with Attachments (SwA)

COM Interop

More Information

Measuring and Analyzing Web Services Performance

More Information

Web Service Enhancements

More Information

Summary