Нужно знать, как асинхронный модуль / обработчик WCF HTTP в IIS7.5 (WAS) может помочь мне

Question

Я читал следующую статью 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, и я немного растерялся.Прежде всего, эта статья написана в 2008 году, поэтому я не уверен, что что-то изменилось в .NET 4.0.

У меня есть клиент, который полностью полагается на синхронные операции.Первая концепция, которую мне трудно понять, это разница между асинхронным поведением на уровне рабочего потока и асинхронным поведением на уровне клиента (при вызове прокси-серверов wcf).Я хотел бы знать следующее:

• Является ли модуль HTTP асинхронного WCF модулем по умолчанию в .NET 4.0?
• Если это не так, и я его включу, будет ли мой клиентпрокси-вызовы также должны быть асинхронными.
• Я понимаю, что проблема с использованием асинхронного модуля WCF HTTP в IIS6 заключается в том, что при поступлении запросов к серверу отсутствует регулирование, поэтому потенциально может быть большое количество запросов.ставится в очередь WCF.Но когда мы имеем дело с WAS, где рабочий процесс ASP.net не задействован, каков механизм, который мешает WCF ставить в очередь слишком много запросов (например, DoS)?MaxConcurrentRequestsPerCpu?

Мой главный вопрос - второй пункт, потому что у меня будут параллельные запросы к моим веб-службам, и мне нужно, чтобы каждый клиентский запрос ждал до завершения операции.Тем не менее, эти веб-сервисы также делают такие вещи, как чтение из базы данных, что задерживает выполнение операций (не так много, ~ 1-2 секунды, но это все еще достаточно важно).Исходя из этого, думаете ли вы, что я должен включить асинхронный модуль WCF HTTP, если это еще не сделано?

Answer 1

Асинхронный модуль WCF HTTP является значением по умолчанию в .NET 4.0 для AppPool, использующего режим интегрированного конвейера.

Если вы посмотрите на обработчики по умолчанию (в \ Windows \ System32 \ inetsrv \ config \ applicationHost.config), вы найдете 3 зарегистрированных обработчика для * .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" />

Обратите внимание на атрибут preCondition для каждого: первые два запускаются в классическом режиме, а последний (упомянутый в сообщении блога WenLong) предназначен для интегрированного режима.

Чтобы включить это, вам просто нужно убедиться, что AppPool, в котором работает ваша служба WCF, имеет:

• .NET Framework Версия: .NET 4.0
• Управляемый конвейерный режим: интегрированный

Это не повлияет на прокси вашего клиента; это влияет только на способ взаимодействия IIS и WCF при длительных вызовах. Возможно, вы захотите взглянуть на некоторые сообщения в блоге AsyncPage / AsyncController (MVC2 / 3), чтобы лучше это понять.

Для настройки количества потоков для обслуживания долго выполняющихся запросов вы обычно используете раздел processModel (в machine.config). Отличная статья о процессе настройки:

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