Need to know how the Asynchronous WCF HTTP Module/Handler in IIS7.5 (WAS) can benefit me

I was reading the following article http://blogs.msdn.com/b/wenlong/archive/2008/08/13/orcas-sp1-improvement-asynchronous-wcf-http-module-handler-for-iis7-for-better-server-scalability.aspx and I am a little confused. First of all this article is from 2008 so I'm not sure if anything changed in .NET 4.0.

I have a client that completely relies on synchronous operations. The first concept that I have a hard time grasping is the difference between asynchronous behavior on a worker thread level and asynchronous behavior on a client level (when calling the wcf proxies). I would like to know the following:

• Is the Asynchronous WCF HTTP Mod开发者_StackOverflowule the default module in .NET 4.0?
• If it is not, and I enable it, will my client proxy calls be asynchronous as well.
• I understand the problem with using the Asynchronous WCF HTTP Module in IIS6 is because there is no throtling on the incoming requests to the server, so there can potentially be a high number of requests being queued up by WCF. But when we are dealing with WAS, where the ASP.net worker process are not involved, what is the mechanism that prevents WCF from queueing up too many requests (i.e. DoS)? MaxConcurrentRequestsPerCpu?

My main question is the second bullet point, because I will have concurrent requests to my web services and I need to have each client request wait until the operation is complete. However, these webserivices are also doing things like reading from a database, which delays completing of the operations (not my much ~ 1 to 2 sec but that's still significant enough). Based on this, do you think I should enable the Asynchronous WCF HTTP Module if it isn't already?

The Asynchronous WCF HTTP Module is the default in .NET 4.0 for an AppPool using Integrated pipeline mode.

If you look at the default handlers (in \Windows\System32\inetsrv\config\applicationHost.config), you'll find 3 registered handlers for *.svc:

<add name="svc-ISAPI-4.0_32bit" path="*.svc" verb="*" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
<add name="svc-ISAPI-4.0_64bit" path="*.svc" verb="*" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
<add name="svc-Integrated-4.0" path="*.svc" verb="*" type="System.ServiceModel.Activation.ServiceHttpHandlerFactory, System.ServiceModel.Activation, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="integratedMode,runtimeVersionv4.0" />

Note the preCondition attribute on each: the first 2 run in classic mode, while the last (which is the one mentioned in WenLong's blog post) is for Integrated mode.

To enable this, you just need to ensure that the AppPool in which your WCF service is running has:

• .NET Framework Version: .NET 4.0
• Managed Pipeline Mode: Integrated

This will not affect your client proxies; this only affects the way IIS and WCF collaborate on long-running calls. You might want to look at some blog posts on the AsyncPage/AsyncController (MVC2/3) to understand this better.

For tuning the number of threads to service long-running requests, you would typically use the processModel section (in machine.config). For a great article on the tuning process, see:

http://blogs.msdn.com/b/endpoint/archive/2011/05/04/wcf-scales-up-slowly-with-bursts-of-work.aspx