WCF Service Performance, is it all about calls per second?

Non-Functional Requirements - Performance

Of all the non-functional or technical requirements, performance is the one that seems to get the most attention. I personally know developers who will spend hours and hundreds of dollars of their customers money in trying to shave milliseconds off a routine in a WCF Service.
In this hub I will dispel some of the common myths surrounding performance using the WCF (Windows Communication Foundation) platform, and provide some metrics I have captured for the WCF services in live production systems. I remember starting out using WCF and not being able to find a single resource that would give me any actual real data to compare my benchmarks against.
I am now into my third major implementation using the WCF service stack, by that I mean big projects at enterprise clients with many interdependent services. The production environments are real, load balanced and representative.
The model I use to build service orientated software utilizes the Manager, Gateway, Engine pattern (GME), thus the metrics are affected by a combination of technology and pattern.

Manager, Gateway, Engine Pattern

 

 

 

What is Performance?

Performance is an indication of the responsiveness of a system to execute any action within a given interval of time.
The performance of any software is  dependent on many factors, most of which have nothing to do with the framework and technology used to build it. Even the most performant software can still have a method that causes an endless loop or a “live lock” that causes a client to wait.A poor server or network could also be the cause of a loss of performance.

The issue then is to ensure that neither the model nor the technology is the cause
of any unacceptable loss of performance.

Technology - WCF, Model - GME

The technology in this instance is WCF, the model advocates that every class is a service in order to leverage the built in plumbing that comes with WCF, but one often hears the question, what about performance?

This is the wrong question to ask, as in reality nobody except developers even cares about performance as long as performance is adequate.
So the actual question is, is the performance adequate? So let’s weigh it all up with all classes as WCF services we automatically benefit from:

WCF Benefits

1. Encrypted calls
2. Authentication
3. Identity propagation
4. Authorization
5. Security audit
6. Transactional propagation
7. Transactional voting
8. Calls timeout
9. Reliability
10. Tracing and logging
11. Profiling and instrumentation
12. Instance management
13. Durability
14. Error masking
15. Fault isolation
16. Channel faulting
17. Buffering and throttling
18. Data version tolerance
19. Synchronization
20. Remotability
21. Queuing
22. Relay
23. Discovery

WCF Benefits

So what about performance

So what about performance, WCF is not free, but it is adequate for most applications, most applications will never notice it. Raw WCF with a single client calling to a single service with no work in it on a laptop provides some 10,000 calls per second, raw C# offers some 300,000 calls per second.
To put the calls per second thing into perspective I would imagine that Amazon runs at about 150 calls per second.
But raw WCF offers no value, in a real system with every aspect of WCF enabled, WCF can manage 100 calls per second on a laptop; in contrast, a C# application with all the equivalent aspects created as bespoke code and enabled manages a maximum of 10 calls per second.
Strange you may think, what has happened?
The WCF aspects underwent years of rigorous testing by some of the most devious minds in the industry and has been optimized and performance tweaked.

So if you care about performance you have  to use WCF as all  its aspects have been performance tested  against hundreds of different scenarios and perform better than the components you have written and only tested against the one or two scenarios that you knew about. 

Cost of WCF

There is a cost to using every WCF  aspect;  every aspect will cause a certain degradation in performance, this is summed in the table below.

Cost of WCF Aspects

ASPECT	COST (%)
Encoding	0
Process Boundry	0
Authorization	0
Authentication	0
Instancing mode	0
Reliability	10
Performance counters	25
Transactions	66
Message Protection	85
Logging and Tracing	95

source: J Lowy

Security is not an option

I don`t know about you, but in my world security is not an option, also service guidelines tell us that services should be secure, so if message protection is mandatory, then you have security enabled and you should then also enable everything else as it will not affect your performance as you have already taken the hit for security.
Only logging and tracing becomes optional, and that can always be turned on and off via configuration files if you need it.

The Metrics

So without boring you, in my tests, with every aspect of WCF turned on in a production environment, calling from a test harness with multiple calls on multiple threads, I typically get the following:
For transactional calls (insert, update, delete) with real business logic behind it, between 25 -40 calls per second.
For select type calls (no transaction) it hovers around 90 - 120 calls per second.
If did did some work on optimizing the code and utilizing all the cores of the server by going parallel where it made sense to do so, I could get more, but who has time for that, this is adequte.
I think of scaling in terms of virtual server instances, so if I want more, I just add another node to the load balancer and get another instance up.