WCF and threading RRS feed

  • Question

  • User-577991800 posted

    I need some clarification here and some concrete answers.

    I understand WCF calls can be made multithreaded capability by setting the ConcurrencyMode to Multiple.

    If I were to host this WCF Service using WAS/IIS then am I correct in saying that for each request that comes through, it will be multithreaded?

    What about if the operation in the WCF method is time consuming and I decided to use a ThreadPool to continue the work, what happens at this point when the method is marked as a Transaction? (TransactionScopeRequired = true and TransactionAutoComplete = true)

    How can I make the WCF scalable so it can process higher requests?



    Thursday, April 26, 2012 2:02 PM

All replies

  • User1941767844 posted

    if you host your WCF service in IIS, then IIS will place each call on it's own thread, giving you the advantage mulitcores on your server.

    If you want a single call to run on many threads, then you need to program this yourself in your code. You would only need this if your service is doing a lot of calculations.

    Check this will help :


    Friday, April 27, 2012 3:58 AM
  • User-742633084 posted

    Hi ahmedilyas,

    For developing WCF service to support high concurrency loads, you might need to consider not only the concurrency configuration at WCF serviceModel side, but also the concurrency at the IIS/asp.net hosting side. Here is a blog article which mentioned about these two sides:

    #WCF Request Throttling and Server Scalability

    And for WCF sides, you need to take care of the concurrency & instancing mode used by your service and adjust the throttling settings accordingly. These ones can help ensure at runtime your WCF service will create enough service instances to handle concurrent requests incoming.

    #Sessions, Instancing, and Concurrency

    #Using ServiceThrottlingBehavior to Control WCF Service Performance

    #WCF Throttling

    while for the ASP.NET/IIS side, there is a default limit of maximum of threads used for handling incoming requests (for ASP.NET or WCF or webservice calls). So in order to make the server really able to handle large number of concurrent calls, we might also need to adjust the default maximum threads limit of IIS application pool(also mentioned in the first reference article above).

    And another quick means is to set the "maxProcesses" of the IIS application pool to > 1 (default is 1). That means IIS will start multiple processes for the certain application pool for hosting the configured web application. And since the IIS threads limit are per process based, use >1 process number will increase the threads capacity also. However, when involving multiple worker processes for a single application pool, we need to make sure the ASP.NET or WCF service application do have proper state management logic because different processes cannot share state info(like in-memory cache, session, static class members ,etc...) with each other.

    #Process Model Settings for an Application Pool <processModel>

    In addition, you can first start by adjusting the WCF specific concurrency/throttling settings and then do some load testing and use performance counters to watch the behavior. In most cases, adjust those setting would be enough.

    Monday, April 30, 2012 2:48 AM
  • User-577991800 posted



    thank you. that is such a great response. I will be sure to check this out.

    What about if for example I decided we dont wish to use IIS for hosting the WCF service but instead Windows Service. The WCF service at all times will be using MSMQIntegratedBinding - so what changes here in terms of threading and requests coming into the service?

    Monday, April 30, 2012 5:49 AM
  • User-742633084 posted

    HI ahmedilyas,

    In case you use non-IIS host and msmq binding, then things get changed some. Here is the basic picture:

    * the WCF throttling/concurrency setting remains the same as it controls how WCF create new service instances based on new client request or session or singleton and whether it allows concurrent processing or not

    * for the underlying threads used for processing WCF requests, it no longer depend on the IIS/ASP.NET's thread pool model, but should rely on the .NET managed(clr) thread pool:

    #The Managed Thread Pool h

    * and finally, the more underlying MSMQ layer. since the transport layer is based on MSMQ, you also need to verify if there is any MSMQ specific configuration that need to set for large concurrent requests scenario. But personally I don't think it would be a big problem since MSMQ is a one-way and async based messaging component.

    Friday, May 4, 2012 4:43 AM