Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post May 04, 2012 08:43 AM by Steven Cheng - MSFT
Apr 26, 2012 06:02 PM|LINK
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 =
How can I make the WCF scalable so it can process higher requests?
Apr 27, 2012 07:58 AM|LINK
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 :
Apr 30, 2012 06:48 AM|LINK
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
#Sessions, Instancing, and Concurrency
#Using ServiceThrottlingBehavior to Control WCF Service Performance
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.
Apr 30, 2012 09:49 AM|LINK
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
May 04, 2012 08:43 AM|LINK
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
* 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.