Instance Context mode
InstanceContextMode controls how service instances are allocated when responding to client calls. The InstanceContextMode can be set to the following values:
single– assigns a service instance to all client calls.
percall– assigns a service instance to each client invocation.
persession– assigns a service instance to each client session.
The default setting for InstanceContextMode is PerSession
concurrency mode
ConcurrencyMode controls how many threads are allowed to enter the service at a time. ConcurrencyMode can be set to one of the following values:
single– One thread can enter the service at a time.
reentrant– can have one thread to enter the service at a time, but allow callbacks.
multiple– can have multiple threads entering the service at a time.
The default setting for ConcurrencyMode is single.
Instance context mode, concurrency mode, and performance
InstanceContextMode and ConcurrencyMode settings can affect each other, so when you understand how they affect performance, you must look at both settings. For example, when you set InstanceContextMode to Percall, the ConcurrencyMode setting is ignored. This is because each client call is routed to the new service instance, so only one thread will run in the service instance at a time. When InstanceContextMode is set to single, only one service instance is created, so concurrencymode affects the throughput of the application.
There are many reasons to set InstanceContextMode to single, including the following:
- Creating a service instance requires a lot of processing work. When multiple clients access the service, allowing only one service instance to be created can reduce the amount of processing required.
- A service instance can create multiple objects. Setting ConcurrencyMode to single reduces the cost of garbage collection because the objects created by the service are not created and destroyed for each invocation.
- By setting ConcurrencyMode to single, you can share service instances across multiple clients.
If both ConcurrencyMode and InstanceContextMode are set to single, only one client call pass is allowed at a time. This can lead to large bottlenecks if there are a large number of clients.
The performance characteristics of setting InstanceContextMode to single and setting ConcurrencyMode to Reentrant are the same as when you set ConcurrencyMode to single. This is because only one client thread is allowed to enter the service at a time.
When InstanceContextMode is set to Percall, a new service instance context is created for each client invocation (by default, this represents a new service instance) and destroyed when the client call completes. Because service instances are only available when making calls, all resources that they might access are freed when the call is complete. Because a new service instance is assigned to each call, some overhead is incurred. However, because each client acquires its own service instance, there is no synchronization problem. When a large number of client calls occur at the same time, a large number of service instances are created. When this happens, make sure that the service instance allocates only those resources that it needs to work properly.
If ConcurrencyMode is set to multiple, multiple client calls can pass, but it is the responsibility of the developer to manually synchronize all access to the shared data. This means that only one thread at a time can access the shared data, which causes all calls to access the shared data to be queued in the order. This violates the original intention of setting ConcurrencyMode to multiple.
When InstanceContextMode is set to Percall, the ConcurrencyMode setting has no effect on throughput. Each client invocation obtains its own service instance, so there is only one thread to which each service instance is called. When InstanceContextMode is set to PerSession, each session acquires its own service instance. For more information about sessions, see Using Sessions (possibly English web pages). When using PerSession, you must use a binding that supports sessions. The following table shows which binding support sessions are provided by the system. The default session settings are enclosed in parentheses.
binding |
session (default) |
BasicHttpBinding |
No |
Wshttpbinding |
No, reliable session, (secure session) |
Wsdualhttpbinding |
(reliable session), secure session |
WSFederationHttpBinding |
(none), reliable session, secure session |
NetTcpBinding |
(transport), reliable session, secure session |
NetNamedPipeBinding |
None, (transmission) |
NetMsmqBinding |
(none), transmission |
NetPeerTcpBinding |
No |
MsmqIntegrationBinding |
No |
Basichttpcontextbinding |
No |
Nettcpcontextbinding |
(transport), reliable session, secure session |
Wshttpcontextbinding |
No, reliable session, (secure session) |
Performance impact of WCF instance context patterns and concurrency patterns