Performance and Scalability

Applies to: Windows Communication Foundation

Published: June 2011

Author: Robert Dizon

This topic contains the following sections.

• Introduction
• Design Consideration
• Performance Strategy and Execution
• Additional Resources

Introduction

Performance is the overall time it takes to complete a request. This number is affected by server resources, and communications overhead. Throughput is the number of requests that can be processed per unit of time. Scalability is the ability to improve performance as additional, or more powerful servers are added to the network. In WCF, the most important considerations for performance, throughput, and scalability are the channel overhead, the number of service hops, and the server hosting model.

• Channel Overhead. The bindings that configure different parts of the channel stack are the most important factors to consider for channel overhead. When bindings are used by some processes, they are not available to others.

• Service Hops. Another point to consider is the number of service hops that must be made for a given application, and the number of services that a client request calls. As the number of requests increases, the open communications channels can become overloaded. Overloads can slow performance and affect scalability for all the applications, not just the application that is making the requests.

• Server Hosting Model. The type of server hosting model is another important issue. In Windows Server 2003, you can use either IIS 6 for HTTP services, or Windows Service for non-HTTP protocols. Windows Server 2008 provides the option to use the Windows Activation Service (WAS) for all protocols.

The following illustration depicts three-tier architecture with end-to-end integration points, or hops.

• Hop 1. This hop is from the client browser or desktop client (1) to the WCF service. It is possible that there are configuration settings on the client side.

• Hop 2. This hop, which originates from the client, is an IIS application server (2) that hosts a WCF service (3). This hop requires two separate configuration settings.

• Hop 3. This hop is from the business layer to the data access layer. If the destination from hope 4 is an ERP, data mapping code will exist for the ERP-specific data format. If the destination is a database, use data mapping that is specific to that database's data layout, along with any other necessary configuration.

• Hop 4. This hop is from the data access layer to the ERP. There are possible configuration settings at the front-end application server (5), or the database (5).

Although there are four hops, bottlenecks usually occur at hop 1 and hop 4.

As the figure illustrates, there are potentially five areas that require configuration management. You should make sure you understand the following issues.

• From Hop 1. Depending on the application's requirements, optimize the WCF client (1) configuration settings for the service timeout, and the size of the message that comes back from the WCF service call. The configuration of the IIS server that hosts the WCF service should be optimized for buffer recycling, and timeouts.

• From Hop 2. The WCF service (3) should be optimized for transport settings, and message size buffers.

• From Hop 3. If possible, at the data access layer, include data mapping optimizations in the WCF code, or use additional WCF configuration settings (4).

• From Hop 4. The hop from the data access layer to the ERP may require that either the front-end application server or the interface to the database be optimized (5).

Design Consideration

It is always a good practice to conduct a detailed design analysis before you begin a project, but this is particularly true for an enterprise-level integration project. You must consider the different technologies that must interoperate, messages that travel across different internal and external domains, and configuration management that can affect how communications flow from one technology to another.

The first important decision you must make is which transport to use for the WCF service. The WCF programming model separates the endpoint operations (the service contract) from the transport mechanism that connects the two endpoints. To transfer data between endpoints requires a binding, which binds the service contract implementation to the address. The transport itself sends or receives the serialized form of a message to and from another application. The three types of transports to choose from are HTTP, TCP, and named pipes. Although the HTTP protocol is not connection based (once the response is sent, no state is maintained), in WCF its transport binding is optimized for interoperability with legacy non-WCF systems. If all the communicating parties use WCF, then TCP-based or named pipes-based (NetTcpBinding and NetNamedPipeBinding) bindings are faster.

TCP is a connection-based, stream-oriented delivery service with error detection and correction. Connection-based means that a communication session between hosts is established before any data is exchanged. The WCF TCP transport is optimized for the scenario where both ends of the communication use WCF. This binding is the fastest WCF binding for scenarios that involve communicating between different machines.

The named pipes transport is an object in the Windows operating system kernel. When communication is required between different WCF applications on a single computer, and you want to prevent any communication from another machine, then use the named pipes transport. An additional restriction is that processes running from Windows Remote Desktop may be restricted to the same Windows Remote Desktop session unless they have elevated privileges.

For more information, see "Choosing a Transport" located at https://msdn.microsoft.com/en-us/library/ms733769.aspx.

Another design consideration is the choice of an authoritative source for authentication and authorization. If you do not use an ERP, then the design is straightforward. The front-end web application and the WCF service layer can use either Windows Authentication or Active Directory.

If you do use the ERP, then there are more issues to consider. If the front-end web application requires that the user log on, the user name and password must be passed to the ERP authentication and session module from the WCF services. This must occur without the involvement of Active Directory or an ASP.NET/SharePoint security context. After the ERP authenticates the user, it issues a session cookie that the browser uses to maintain state. The correct configuration is important at all levels, but is particularly important at the WCF service level and at the web application's front end. You must ensure that the session does not time out, and that any data that the web application's session state persists is not lost.

Several articles on MSDN provide guidance on how to use the WCF authentication service.

• "Customize User Login When Using the WCF Authentication Service" on MSDN at https://msdn.microsoft.com/en-us/library/bb398862.aspx.

• "Use Non-default Membership Provider for WCF Authentication Service" on MSDN at https://msdn.microsoft.com/en-us/library/bb386455.aspx.

Performance Strategy and Execution

As the WCF services are built and unit tested during the development phase, begin to plan for and design integration, performance, and scalability testing. These tests have the following objectives:

• Integration testing should be conducted by vertically slicing and benchmarking the system. The vertical divisions are from the client to the web service, from the web service to the app service, and then from the app service to third-party applications.

• Performance testing strategies should be conducted end-to-end for every web service.

• Create enough performance and scalability test data so that you can run tests with low, medium, and high volume loads for each web service.

All tests should occur in cycles. Each cycle tests a different category of service type, and each cycle should use pre-defined test data classifications and test data sizes. In the following table, cycle 1 test the account data services, cycle 2 tests the performance data services, and cycle 3 tests the transaction data services. The table illustrates the tests, their objectives, and the test data that is used for a high volume load.

Table 1. Sample Service Cycles - Data Volumes

If at all possible, your performance tests should not only use different amounts of data, but they should also include real-time data for more accurate metrics. If you cannot meet all these goals, then the test data volume should be as close as possible to the maximum volume of data that you think the application will need to process.

After each performance test, you must compile and analyze the results. Here are some guidelines.

• Determine the average execution time, in seconds, for each request, both for individual components and from end to end.

• Analyze any execution errors. These may occur in the messages, in the events, or in the process instance.

• Inspect and save any server logs for a more detailed analysis of exceptions.

• Compile all of the information and fill in a performance execution tracking table. The following table is an example.

Table 2. Sample Performance Execution Tracking

If there are any puzzling errors or performance issues, make an entry in the table and inform a developer. If you can, provide additional debugging information such as component identification, as well as detailed server logs.

For information on Performance Comparison of WCF visit MSDN at https://msdn.microsoft.com/en-us/library/bb310550.aspx

For open source WCF Load Test application on CodePlex at http://wcfloadtest.codeplex.com/

Additional Resources

Choosing a Transport https://msdn.microsoft.com/en-us/library/ms733769.aspx

Customize User Login When Using the WCF Authentication Service https://msdn.microsoft.com/en-us/library/bb398862.aspx

Use Non-default Membership Provider for WCF Authentication Service https://msdn.microsoft.com/en-us/library/bb386455.aspx

Previous article: Service Reusability

Continue on to the next article: Production Configuration Settings