WCF Performance Counters

WCF offers its own set of performance counters, which allow you to observe the live performance of your services, from various aspects. However, WCF does not publish performance counter data by default, and even when enabled, you can choose which categories of counters are published. As you expect, this is designed so with a reason.

Shared memory concerns

Besides the obvious performance overhead, managed performance counters also consume memory that is shared among .NET processes running on the machine. This committed memory is backed by the page file, so its size counts to the overall system commit. The memory area is set up per performance counter category, and has a default size of 128KB.

So, the size of this memory area should be kept small. However, when all memory counters are enabled WCF, then – depending on your services – the counters (or more precisely, counter instances) will consume a considerable part of these shared memory areas:

• 15 performance counters for each instance of operation (per endpoint across all services).

• 19 performance counters for each instance of endpoint (across all services).

• 33 performance counters for each service.


This means quite many counter instances for the category “ServiceModelOperation”. If you have say 10 operations per endpoint, 10 endpoints in each service and 10 services, you’ll end up with 10 x 10 x 10 x 15 = 15 000 performance counter instances for this category.

But how many bytes does one instance need? Among other factors, this also depends on the name of the counter instances, which tend to be long in WCF (combination of service, endpoint and operation name). According to my measurements, they need approximately 320-350 bytes each.

Summing it up

Writing this back to our formula above, our hypothetical scenario would need 15 000 x 350 = 5 250 000 bytes of shared memory for “ServiceModelOperation” alone. Sure enough, in such cases the default 128KB won’t be enough for this category. When this happens, WCF notifies you by writing "System.InvalidOperationException: Custom counters file view is out of memory." to the application event log and in the ServiceModel trace.

The solution is to specify a fileMappingSize suitable for your needs in either machine.config or the registry. I’d recommend the latter, since the registry setting allows doing this per category.