Services have a built-in defense mechanism, called throttles, to prevent them from taking over too much of the system's resources. There are three of these throttles that are controllable through a ServiceThrottlingBehavior that you can supply to the service.

• MaxConcurrentCalls limits the number of service calls (messages) that the service will have processing at one time. You may get less than this maximum number if the concurrency or instancing behavior of your service does not allow processing multiple messages.
• MaxConcurrentSessions limits the number of persistent connections (sessionful channels) that the service will accept messages from at one time. Again, you need a minimum level of concurrency in your service for this to become an issue.
• MaxConcurrentInstances limits the number of copies of the service (instance contexts) that can exist. This is only interesting if your service is permitted to have multiple instances.

Knowledge of these throttle values can help you track down problems when you are achieving concurrency for a while with client connections but suddenly hit a wall when the number of clients is pushed farther. These throttles are going to stack with the number of clients that are buffered at the transport level, for example by having the connections sit in kernel TCP buffers. You can tell the two apart because the throttles are what drive the steady-state simultaneous client processing load while the transport quotas stack with the throttles for the initial maximum client backlog.

The number of instances is unlimited by default, but there are very conservative default throttles of 10 simultaneous sessions and 16 simultaneous service calls. During the beta, the number of sessions was unlimited and the MaxConcurrentCalls throttle was set to 64, which made it easy to guess when someone had a throttling problem. They would report that the throughput mysteriously fell off somewhere between 50 and 100 clients.

Next time: Slow Proxy Discovery