WCF Performance Tuning

Posted on August 17, 2010 by Sanjit Sil

WCF was introduced to overcome the constraints of previous distributed technologies like ASP.NET Web Services, WSE, .NET Enterprise Services and .NET Remoting and to provide a performance boost in addition. For an introduction to WCF please read my first WCF article - WCF Tutorial . Performance is a central goal for web or app site, expecially since Google now includes site responsiveness a factor in their ranking algorithm. For ASP.NET optimization tips, please see my article titled 50 Tips to Boost ASP.NET Performance. In this article I will discuss WCF performance tuning techniques. Use DataContractSerializer: Serialization is the process of converting an object instance into a portable and transferable format. Xml Serialization is popular for its interoperability and binary Serialization is more useful for transferring objects between two .NET applications. System.Runtime.Serialization.DataContractSerializer is designed for WCF but can also be used for general serialization. The DataContractSerializer has some benefits over XmlSerializer: 1. XmlSerializer can serialize only properties but DataContractSerializer can serialize fields in addition to properties. 2. XmlSerializer can serialize only public members but DataContractSerializer can serialize not only public members but also private and protected members. 3. In performance terms, DataContractSerializer is approximately 10% faster than XmlSerializer. Select proper WCF binding: System-provided WCF bindings are used to specify the transport protocols, encoding, and security details required for clients and services to communicate with each other. The below are the available system-provided WCF bindings: 1.BasicHttpBinding: A binding suitable for communication with WS-Basic Profile conformant Web Services such as ASMX-based services. This binding uses HTTP as the transport and Text/XML for message encoding.

2. WSHttpBinding: A secure and interoperable binding suitable for non-duplex service contracts. 3. WSDualHttpBinding: A secure and interoperable binding suitable for duplex service contracts or communication through SOAP intermediaries. 4. WSFederationHttpBinding: A secure and interoperable binding that supports the WS-Federation protocol, enabling organizations that are in a federation to efficiently authenticate and authorize users. 5. NetTcpBinding: A secure and optimized binding suitable for cross-machine communication between WCF applications 6. NetNamedPipeBinding: A reliable, secure, optimized binding suitable for on-machine communication between WCF applications. 7. NetMsmqBinding: A queued binding suitable for cross-machine communication between WCF applications. 8. NetPeerTcpBinding : A binding which enables secure, multi-machine communication. 9. MsmqIntegrationBinding : A binding that is suitable for cross-machine communication between a WCF application and existing MSMQ applications. In this context Juval Lowry has presented a nice decision making diagram:

It should be noted that WCF also allows us to define our own custom bindings. Use Tracing: Tracing can track all the events or specified events in a program. By default it is off. For debugging purposes we have to make enable it explicitly either through code or using a config file setting which is preferable. If debugging is not required we should disable tracing. For more details reader can read my article titled Tracing in WCF. Close Proxy: The proxy represents a service contract. It provides the same operations as services contract along with some additional methods for managing the proxy life cycle and the connection to the service. It is a recommended best practice to always close the proxy when the client is finished using it. When we close the proxy, the session with the service is terminated and the connection is closed as well and thus can serve to process new requests in better way. It should be noted that calling a proxy in a using statement (see the below code snippet) is actually not the optimal or safest method.
using (ServiceProxy proxyClient = new ServiceProxy()) { proxyClient.SomeFunction(); } The above code will be translated to something as follows:

ServiceProxy proxyClient = new ServiceProxy(); try { proxyClient.SomeFunction(); } finally { if (proxyClient != null) ((IDisposable)proxyClient).Dispose(); }

The problem with this method is that proxyClient.Dispose() will throw an exception when the proxy is in a faulted state .So to close the proxy even under faulted state the below is the suggested approach:
ServiceProxy proxyClient = new ServiceProxy(); try { proxyClient.SomeFunction(); proxyClient.Close(); } finally { if (proxyClient.State != System.ServiceModel.CommunicationState.Closed)

{ proxyClient.Abort(); } }

Throttling: Throttling is a way of mitigating potential DoS (denial of service) attacks. Using ServiceThrottlingBehavior we can set smooth loading and resource allocations on the server. In WCF, there are three service-level throttles that are controlled by ServiceThrottlingBehavior. 1. MaxConcurrentCalls: The maxConcurrentCalls attribute lets us specify the maximum number of simultaneous calls for a service. When the maximum number of simultaneous calls has been met and a new call is placed, the call is queued and will be processed when the number of simultaneous calls is below the specified maximum number. The default value is 16. 2. MaxconcurrentSessions: The maxconcurrentSessions attribute specifies the maximum number of connections to a single service. The channels below the specified limit will be active/open. It should be noted that this throttle is effectively disabled for non-sessionful channels (such as default BasicHttpBinding).The default value is 10. 3. MaxConcurrentInstance: The maxConcurrentInstance attribute specify the maximum number of simultaneous service instances. While receiving new instance request the maximum number has already been reached, the request is queued up and will be completed when the number of instances is below the specified maximum. The default value is total of the two attributes maxConcurrentSessions and maxConcurrentCalls. From general feedback it is has been noted that the default settings for the above mentioned three attributes are very conservative and are insufficient in real production scenarios and thus developers need to increase those default settings. Hence Microsoft has increased the default settings in WCF4.0 as follows: 1. MaxConcurrentSessions: default is 100 * ProcessorCount 2. MaxConcurrentCalls: default is 16 * ProcessorCount

3. MaxConcurrentInstances: default is the total of MaxConcurrentSessions and MaxConcurrentCalls Now we have a new parameter which is the multiplier ProcessorCount for the settings. The main reason for this is that we do not need to change the settings in deployment from a low end system to a multiple processor based system. The value for MaxConcurrentSessions is also increased from 10 to 100.

Quotas:
There are three types of quotas in WCF transports: 1. Timeouts. Timeouts are used for the mitigation of DOS attacks which rely on tying up resources for an extended period of time. 2. Memory allocation limits: Memory allocation limits prevent a single connection from exhausting the system resources and denying service to other connections. 3. Collection size limits: Collection size limits restrict the consumption of resources which indirectly allocate memory or are in limited supply. As per MSDN the transport quotas available for the standard WCF transports: HTTP(S), TCP/IP, and named pipes are as follows: Sl.N o Name Type Min Valu e 0 Defa ult Value 1 min Description

CloseTimeout

TimeSp an

Maximum time to wait for a connection to close before the transport will raise an exception.

ConnectionBufferSize

Integer

8 KB

Size in bytes of the transmit and receive buffers of the

underlying transport. Increasing this buffer size can improve throughput when sending large messages. 3 ConnectionLeaseTimeout Timesp an 0 5 Min Maximum lifetime of an active pooled connection. After the specified time elapses, the connection will close once the current request is serviced. This setting only applies to pooled connections. 4 IdleTimeout Timesp an 0 2 Min Maximum time a pooled connection can remain idle before being closed. This setting only applies to pooled connections. 5 ListenBacklog Integer 0 10 Maximum number of unserviced connections that can queue at an endpoint before additional connections

are denied. 6 MaxBufferPoolSize Long 0 512 KB Maximum amount in bytes of memory that the transport will devote pooling reusable message buffers. When the pool cannot supply a message buffer, a new buffer is allocated for temporary use. Installations that create many channel factories or listeners can allocate large amounts of memory for buffer pools. Reducing this buffer size can greatly reduce memory usage in this scenario. 7 MaxBufferSize Integer 1 64 KB Maximum size in bytes of a buffer used for streaming data. If this transport quota is not set or the transport is not using streaming, then the quota value is the same as the

smaller of the MaxReceivedMessag eSize quota value and Integer.MaxValue. 8 MaxInboundConnections 1 10 Maximum number of incoming connections that can be serviced. Increasing this collection size can improve scalability for large installations. Connection features such as message security can cause a client to open more than one connection. Service administrators should account for these additional connections when setting this quota value. Connections waiting to complete a transfer operation can occupy a connection slot for an extended period of time. Reducing the timeouts for send and receive

operations can free up connection slots quicker by disconnecting slow and idle clients. 9 MaxOutboundConnectionsPerE ndpoint Integer 1 10 Maximum number of outgoing connections that can be associated with a particular endpoint. This setting only applies to pooled connections. 10 MaxOutputDelay Timesp an 0 200 ms Maximum time to wait after a send operation for batching additional messages in a single operation. Messages are sent earlier if the buffer of the underlying transport becomes full. Sending additional messages does not reset the delay period. 11 MaxPendingAccepts Integer 1 1 Maximum number of channels that the listener can have waiting to be

accepted. There is an interval of time between a channel completing an accept and the next channel beginning to wait to be accepted. Increasing this collection size can prevent clients that connect during this interval from being dropped. 12 MaxReceivedMessageSize Long 0 64 KB Maximum size in bytes of a received message, including headers, before the transport will raise an exception 13 OpenTimeout Timesp an 0 1 Min Maximum time to wait for a connection to be established before the transport will raise an exception. 14 ReceiveTimeout Timesp an 0 1 Min Maximum time to wait for a read operation to complete before the transport will raise an exception.

15

SendTimeout

Timesp an

1 Min

Maximum time to wait for a write operation to complete before the transport will raise an exception.

Without proper settings of quotas (see the below configuration settings) the exceptions will rise which may cause to terminate the service.
xxx

Other quotas of the ReaderQuotas property that can be used to restrict message complexity to provide protection from denial of service (DOS) attacks, these are: 1. MaxDepth: The maximum nested no depth per read. The default is 32. 2. MaxStringContentLength: The maximum string length allowed by the reader. The default is 8192. 3. MaxArrayLength: The maximum allowed array length of data being received by WCF from a client. The default is 16384. 4. MaxBytesPerRead: The maximum allowed bytes returned per read. The default is 4096. 5. MaxNameTableCharCount: The maximum characters in a table name. The default is 16384.

WCF Tracing
Posted on August 20, 2010 by Sanjit Sil

After deploying application a proper troubleshooting policy should be ready in order to perform maintenance activity of our project life cycle. Here we will see different tools available from Microsoft within visual studio in order to manage, configure, debug and troubleshoot WCF service after deployment. Note that if you are unfamiliar with WCF, please read my WCF Tutorial . WCF Tracing can track all the events or only specified events in the program. Tracing is built upon the System.Diagnostics namespace of the .NET Framework. The Debug and Trace classes under this namespace are responsible for debugging and tracing purpose. Tracing is turned off by default and needs to be enabled to start using tracing. We can enable tracing by two ways. One is through code and another is from config file. Enabling tracing in configuration is the optimal method since we can easily turn it on and off as required. When debugging is no longer required we should turn tracing enable off.

ENABLING TRACING

The following code snippet will enable tracing through configuration file:
<system.diagnostics>

<trace autoflush="true" />

<sources>

<source name="System.ServiceModel"

switchValue="All">

<listeners>

<add name="TraceListeners"

type="System.Diagnostics.XmlWriterTraceListener"

initializeData= "c:\Log\trace.svclog"/>

</listeners>

</source>

</sources>

</system.diagnostics>

In this example, the name and type of the trace listener is specified. The Listener is named TraceListeners and the standard .NET Framework trace listener (the native format for the tool - System.Diagnostics.XmlWriterTraceListener) is added as the type. The initializeData attribute is used to set the name of the log file for that Listener. Here the fully qualified file name is used as c:\Log\trace.svclog. Tracing Levels: Tracing Levels: The tracing level is controlled by the switchValue setting. The available tracing levels are described below: SL. No 1. 2. Level Tracked Events Content of the Tracked Events

Off Critical

No traces are emitted. Out of memory exception, Stack overflow exception, Application start errors, System hangs, Poison messages All exception are logged Unexpected processing has happened. The application was not able to perform a task as expected. However, the application is still up and running. A possible problem has occurred or may occur, but

3.

Error

4.

Warnings

Timeout exceeded, Credential rejected, throttling exceeded, receiving

queue nearing capacity

the application still functions correctly. However, it may not continue to work properly. Important and successful milestones of application execution, regardless of whether the application is working properly or not. Low level events for both user code and servicing are emitted. Flow events between processing activities and components. Application may function properly. All events are emitted.

5.

Information

Channels and endpoints created, message enters/leaves transport, configuration read, general helpful information

6.

Verbose

Debugging or application optimization

7.

Activity Tracing

Tracing for transfers, activity boundaries, start/stop

8.

All

All listed events

Trace Sources: WCF defines a trace source for every assembly. Traces generated within an assembly are accessed by the listeners which are defined for that source. The below trace sources are defined:

System.ServiceModel: Logs all stages of WCF processing, whenever the configuration is read, a message is processed in transport, security processing, a message is dispatched in user code, and so on. System.ServiceModel.MessageLogging: Logs all messages that flow through the system. System.IdentityModel: Logs data for authentication and authorization. System.ServiceModel.Activation: Logs the activity of creating and managing service hosts. System.IO.Log: Logging for the .NET Framework interface to the Common Log File System (CLFS). System.Runtime.Serialization: Logs when objects are read or written. CardSpace: Logs messages related to any CardSpace identity processing that occurs within WCF context.