WCF: Don't Rely On Default Configuration Values

28. September 2007 05:15

Never rely on the default values for your service configuration.  This is something that seems to bite a lot of developers that are new to WCF.  The large majority of the settings default to predetermined values intended to help create a more secure "out of the box" service.  However, many of these settings are not very conducive for scalability and performance.

Let's look at a few settings with default values that can be problematic. 

MaxConcurrentCalls is used to define a limit on the number of messages that can be processed by a service at any given time.  Another way of looking at it is the number of threads that will be available for serving requests.  The default value for MaxConcurrentCalls is 16.  Once there are 16 concurrent calls, the requests will start getting queued.  Depending upon the throughput required for your scenario, the default value may not be sufficient. 

MaxConcurrentSessions has a similar problem.  This setting places an upper bound on the number of sessions permitted by your service at any given time.  The default value is 10, which means only 10 sessionful clients would be allowed to simultaneously connect to the service.

MaxReceiveMessageSize of the WsHttpBinding specifies the maximum number of bytes allowed for a message.  The default value is a measly 65.536 bytes.  If you move very far beyond a "Hello World" WCF service, you are going to need more than 65,536 bytes for a message.  This is especially true for security configurations that have require sizable SOAP header in addition to the actual payload of the message body. 

These are just a few of the settings that you should review more closely.  Never make the assumption that WCF will auto-magically apply the configuration values that work best for your service and environment.  You should always conduct proper testing of your configuration.  Most likely, it will require a bit of tweaking to get the values just right for your particular scenario.  Failure to do so can (and often will) result in poor performance and/or scalability.

Don't get caught falsely accusing WCF of poor performance simply because you didn't properly configure the service!

Comments are closed

About Me

I'm a passionate software developer and advocate of the Microsoft .NET platform.  In my opinion, software development is a craft that necessitates a conscious effort to continually improve your skills rather than falling into the trap of complacency.  I was also awarded as a Microsoft MVP in Connected Systems in 2008, 2009, and 2010.


Can’t code withoutThe best C# & VB.NET refactoring plugin for Visual Studio
Follow jeff_barnes on Twitter

View Jeff Barnes's profile on LinkedIn

 

Shared Items

Disclaimer

Anything you read or see on this site is solely based on my own thoughts.  The material on this site does not necessarily reflect the views of my employer or anyone else.  In other words, I don't speak for anyone other than myself.  So, don't assume I am the official spokesperson for anyone.