The first think I tell them is to check their WCF throttling settings. The throttling behavior in WCF controls how many instances and session WCF can create and manage at once.
These settings also depend on the binding you use. For example if you have a single proxy on the client side that sends many async calls at once, and you use basicHttpBinding, WCF will by default create many instances on the service side, this is because basicHttpBinding does not support sessions. If you change the binding to wsHttpBinding which supports sessions, you will end up using a single instance (this of course depends on the instance context mode of your service).
In WCF 3.5 the throttling settings were quite low, but in .NET 4 they were increased and now they depend on the number of cores your machine has.
Of course this is the obvious reason, but after solving this issue, some people find another problem with concurrent calls, usually when making a lot of concurrent calls that span many service instances. The problem with creating a lot of service instances at once, even after increasing the throttling values, relies in the fact the WCF uses the ThreadPool to create to queue the work, and the ThreadPool controls how many threads are available for work and how to create new threads (this is the MinIOThreads setting). The ThreadPool has a minimum of threads which is set according to the machine’s CPU, and can be changed if needed (note the bug that exists in the CLR in .NET 3.5).
Recently, a new problem was found with the way the ThreadPool’s managed IO threads, which can affect the use of WCF over time in high loads. You can follow the following blog post for more information about this behavior and how to workaround it.
There are other settings that might affect throttling, such as ASP.NET settings, and other System.Net settings. If you encounter scaling issues, I suggest you also check the following blog post for performance tips.