Paolo Pialorsi - Bridge The Gap!

WCF configuration default limits, concurrency and scalability

Often I need to enumerate to my customers all the main configuration parameters related to default limits, concurrency and scalability of WCF, thus I decided to keep truck of all those parameters and features in order to have a unique place for reference.

From a configuration point of view, WCF provides some parameters that influence the availability and scalability of solutions. These parameters are:

• configuration/system.serviceModel/behaviors/serviceBehaviors/behavior/serviceThrottling/@maxConcurrentCalls: defines the maximum number of messages actively processed by all the service instances of a ServiceHost. The default value is 16. Calls in excess of the limit are queued.
• configuration/system.serviceModel/behaviors/serviceBehaviors/behavior/serviceThrottling/@maxConcurrentInstances: defines the maximum number of service instances that can execute at the same time. The default value is Int32.MaxValue. Requests to create additional instances are queued and complete when a slot below the limit becomes available.
• configuration/system.serviceModel/behaviors/serviceBehaviors/behavior/serviceThrottling/@maxConcurrentSessions: defines the maximum number of sessions that a ServiceHost instace can accept at one time. The default value is 10. The service will accept connections in excess of the limit, but only the channels below the limit are active (messages are read from the channel).

These configuration parameters can also be configured by code using the ServiceThrottlingBehavior configuration.

Another set of interesting configuration parameters are those related to the default limits of messages, serialization measures, etc. of the various bindings. Here are the main ones, with the default values for each of the main bindings:

Sorry for the big table layout. Many of these parameters are taken "as they are" from the product documentation. The only thing I've done is to write them in a unique and common place, for further reference. The red values seem to be different (using .NET Reflector) from the MSDN documented values. I hope that I didn't make mistakes, otherwise please drop me a comment ... thanks.

One last set of configuration parameters that in general influence the scalability of a WCF solution are the InstanceContextMode and ConcurrencyMode properties of the ServiceBehavior. These parameters are configurable only within the service code, and not in XML configuration, because they relate to the runtime behavior of the service and the service developer should be aware of their values. The InstanceContextMode parameter determines how many instances of the service have to be created by the WCF runtime. The possible values are:

• PerCall: a new InstanceContext object is created for each call.
• PerSession: a new InstanceContext object is created for each session. If the channel does not create a session this value behaves as if it were PerCall.This is the default value.
• Single: only one InstanceContext object is used for all incoming calls and is not recycled subsequent to the calls. If a service object does not exist, one is created.

The ConcurrencyMode property relates to the threading behavior of the service. In fact it defines how the service behaves related to multi-threaded scenarios. Here are the possible values:

• Single: the service instance is single-threaded and does not accept reentrant calls. If the InstanceContextMode property is Single, and additional messages arrive while the instance services a call, these messages must wait until the service is available or until the messages time out. This is the default value.
• Reentrant: the service instance is single-threaded and accepts reentrant calls. The reentrant service accepts calls when you call another service; it is therefore your responsibility to leave your object state consistent before callouts and you must confirm that operation-local data is valid after callouts. Note that the service instance is unlocked only by calling another service over a WCF channel. In this case, the called service can reenter the first service via a callback. If the first service is not reentrant, the sequence of calls results in a deadlock.
• Multiple: the service instance is multi-threaded. No synchronization guarantees are made. Because other threads can change your service object at any time, you must handle synchronization and state consistency at all times.

In the following table you can see the matrix of available configurations and behaviors for InstanceContextMode and ConcurrencyMode:

That's all. I hope you will enjoy this reference post.