WCF Performance Counters

We generally need to have a quick set of performance counters to identify a performance issue with a service. Shown below are three new counters that you will find with WCF 4.0. I also want to emphasize on the Calls outstanding counter here since this is one very useful and is indicative of calls getting queued up.



Reports # of active requests as % of max calls

Reports the numbers of messages being processed + in the wait queue as a percentage of MaxConcurrentCalls throttle


Reports # of active requests as % of max sessions

Reports the numbers of active instances + calls in the wait queue waiting for an instance as a percentage of MaxConcurrentInstances throttle


Reports # of active requests as % of max instances

Reports the numbers of messages in the wait queue due to MaxConcurrentSessions throttle

CallsOutstanding ( from 3.0)

Reports the # of calls waiting to be completed

Reports the number of in-progress calls to this service.

Here you see that the %Instance throttle has maxed out. What do you think we should do? You can guess what throttle we are hitting here.





Some common questions when trouble shooting performance problems:

Why are my clients timing out, the service is showing 100% for % of MaxConcurrentCalls?

% of MaxConcurrentCalls gives you an indication of how much closer you are to hitting your max throttle value. This means that if you have a max concurrent call of 10 and you have 10 outstanding calls then you have utilized 100% of your throttle and there is no more work that your service can do. So if you see that your % maxConcurrentCalls is very high it probably indicates you have a very low throttle value. Remember the default is 16 till v3.5 and 16* proc count for v4.0.  Before 4.0 you needed to work this out by checking the calls outstanding throttle and your web.config to figure out this value. These new % performance counters would help you identify if you are hitting the max values from now.

What if % MaxConcurrentSessions is showing 100% ?

We have bumped up the default number of sessions for service throttling behavior to 100 per CPU. But then again if you are seeing that %MaxConcurrentSessions is very high  this means that you have exhausted all your session. This is probably because your clients are not closing either proxies and ter minating sessions when you have less clients or possibly due to a very small MaxConcurrentSessions configuration.

Who by fire

And who by fire, who by water,
Who in the sunshine, who in the night time,
Who by high ordeal, who by common trial,
Who in your merry merry month of may,
Who by very slow decay,
And who shall I say is calling?

And who in her lonely slip, who by barbiturate,
Who in these realms of love, who by something blunt,
And who by avalanche, who by powder,
Who for his greed, who for his hunger,
And who shall I say is calling?

And who by brave assent, who by accident,
Who in solitude, who in this mirror,
Who by his lady’s command, who by his own hand,
Who in mortal chains, who in power,
And who shall I say is calling?

Leonard Cohen

Debugging WCF TimeoutException for a Middle-Tier Application

This is an amazing post by Wenlong giving you a full walkthrough of how we generally go about debugging a performance problems.

Crack Throttling: Debugging WCF TimeoutException for a Middle-Tier Application

One of the key takeaways from this is the emphasis of client settings in your service. These are as important on a server as it is on the client side when you have a middle tier. You have to keep in mind that the middle tier becomes the client for your back end service and all client settings and behaviors apply to your proxy in the middle tier including things like channel caching etc. The below diagram shows you one setting that is  most commonly forgotten when we try to perform common tasks like

  1. Load testing  your service (no middle tier)
  2. Load testing your backend service with a Middle tier which needs to saturate your back end process.


How do I get the Message Body as Xml?

This was one was interesting as the service was exposed as a fully typed service, but the client wanted to modify some parts of the xml. Ideally you can plug into any part to perform these operations, but the general requirement here was that they needed a simple pointer to the Body and didn’t care much about anything else.

Here is an example how how you can access the body similar to an XElement by using the Message directly.


[ServiceContract(Namespace="http://www.sajay.com/")]public interface IClientProxy{    [OperationContract(Action="http://www.sajay.com/getdata",        ReplyAction="http://www.sajay.com/getdataresponse")]    Message DoWork();}IClientProxy proxy = cf.CreateChannel();Message msg = proxy.DoWork();XNode node = XElement.ReadFrom(msg.GetReaderAtBodyContents());



So the service can return a typed object, but the client doesn’t have to handle the message in the same way. Understanding the Message class here helps you appreciate how the serializer and encoder is decoupled from the message representation. Basically WCF does not constrain the native format of your message on either the producer’s or the consumer’s side. It merely conforms to some rules of invoking a set of abstract classes which you wire up by virtue of specifying the encoder and the serializer.

Though we have XML semantics around with abstract classes like the XmlReader/XmlDictionaryWriter etc in conjuction with the Message class, this doesn’t actually mean that WCF converts everything to XML before it can process the message. It merely uses these to invoke the required parts to obtain things like the header/body and other properties.  The Message however can be represented natively in any form like binary/json/atom/ or any whacky type as long as you wire them up properly and can retrieve them in some manner.

This should give you some insight into how much more powerful the message model is compared to simple RPC style contracts.  With 4.0 and workflow services, you will see this becoming more and more the default way of thinking about messages and services.

MessageToXElement.cs (2.90 kb)