WCF Throttling

ServiceThrottlingBehavior is a service-level behavior with three settings that cap resource consumption independently of how many clients are actually trying to connect: MaxConcurrentCalls limits how many messages can be actively executing across the entire service host at once; MaxConcurrentSessions limits how many session-based channels (relevant to InstanceContextMode.PerSession or netTcpBinding sessions) can be open simultaneously; and MaxConcurrentInstances limits how many service instances can exist concurrently, which matters most for PerSession and PerCall instancing where each call or session gets its own instance. These three numbers work together rather than independently — a request might be allowed by MaxConcurrentSessions but still queued because MaxConcurrentCalls is already at its ceiling, since a single session can issue many concurrent calls.

The default throttling values in WCF are conservative and were set with older hardware in mind (historically MaxConcurrentCalls defaulted to 16, MaxConcurrentSessions to 10, and MaxConcurrentInstances to 26 in early versions, with somewhat higher defaults tied to processor count in later releases) — meaning an out-of-the-box WCF service running on modern multi-core hardware is very likely leaving throughput on the table until these values are explicitly raised. The right values are workload-dependent: MaxConcurrentInstances should generally be at least as large as MaxConcurrentSessions for PerSession services since each session needs its own instance, and MaxConcurrentCalls should be tuned relative to how CPU- or I/O-bound each operation is — I/O-bound operations (waiting on a database or downstream API) can sustain a much higher MaxConcurrentCalls than CPU-bound operations without starving the thread pool, since threads mostly sit idle waiting rather than actively computing.

When an incoming call would exceed MaxConcurrentCalls, WCF does not immediately reject it — the message is accepted at the transport level and queued, waiting for an executing call to finish and free up a slot. This means throttling limits don't produce errors under moderate overload; they produce increased latency as calls wait in the queue, which is often the desired behavior since a temporary burst just slows down rather than fails outright. However, if the queue backs up long enough that a client's own operation timeout (or the binding's sendTimeout) elapses before the call is dequeued and executed, the client receives a TimeoutException even though the service technically never actively rejected the call — a subtlety that makes throttling-related failures look like generic network timeouts unless you specifically know to check the throttling counters (exposed via WCF performance counters) during diagnosis.

The real purpose of throttling isn't just capping WCF's own internal counters — it's protecting downstream resources that a flood of concurrent calls would otherwise overwhelm, such as a connection-pool-limited SQL Server database, a rate-limited third-party API, or the CLR thread pool itself. If MaxConcurrentCalls is set far higher than the database's connection pool size, WCF will happily accept far more concurrent calls than the database can actually service, and those calls will pile up waiting on database connections instead of waiting in WCF's own queue — moving the bottleneck downstream rather than eliminating it, and often making the failure mode worse because connection pool exhaustion can produce confusing errors deep in the data access layer rather than a clean, diagnosable WCF-level timeout. Effective throttling configuration treats MaxConcurrentCalls as roughly the minimum of what the service's CPU can handle and what every downstream dependency can sustain, not just an arbitrary large number chosen to 'allow more traffic.'