Рекомендации по размещению в службах IIS
В этом разделе описаны некоторые рекомендации по размещению служб Windows Communication Foundation (WCF).
Реализация служб WCF в виде библиотек DLL
Реализация службы WCF в виде библиотеки DLL, развернутой в каталоге \bin веб-приложения, позволяет повторно использовать службу за пределами модели веб-приложения, например в тестовой среде, которая может не развернуть службы IIS (IIS).
Ведущие приложения служб в приложениях, размещенных в IIS
Не используйте императивные интерфейсы API самообслуживания для создания новых узлов служб, которые прослушивают сетевые транспорты, не поддерживаемые средой размещения IIS (например, IIS 6.0 для размещения служб TCP, так как tcp-связь не поддерживается в IIS 6.0). Такой подход не рекомендуется. Ведущие приложения служб, созданные принудительно, в среде размещения IIS неизвестны. Ключевым пунктом является то, что обработка, выполненная принудительно созданными службами, не принимается во внимание системой IIS, когда она определяет, простаивает ли пул ведущих приложений. В результате приложения, где есть такие принудительно созданные ведущие приложения служб, имеют среду размещения IIS, которая агрессивно удаляет ведущие процессы IIS.
Универсальные коды ресурсов (URI) и размещенные в IIS конечные точки
Конечные точки для службы, размещенной в IIS, должны быть настроены с использованием относительных универсальных кодов ресурсов (URI), а не абсолютных адресов. При этом гарантируется попадание адреса конечной точки в ряд адресов URI, принадлежащих ведущему приложению, и обеспечивается надлежащая активация на основе сообщений.
Управление состоянием и перезапуск процессов
Среда размещения IIS оптимизирована для служб, не поддерживающих локальное состояние в памяти. При появлении множества внешних и внутренних событий система IIS перезапускает ведущий процесс, в результате чего любое непостоянное состояние, сохраненное только в памяти, теряется. Службы, размещенные в IIS, должны сохранять свое состояние во внешней по отношению к процессу среде (например, в базе данных) или в расположенном в памяти кэше, который в случае перезапуска приложения может быть легко восстановлен.
Примечание.
Протоколы WCF, используемые для надежности и безопасности уровня сообщений, используют переменное состояние в памяти. Надежные сеансы WCF и сеансы безопасности могут неожиданно завершиться из-за перезапуска приложений. Приложения, размещенные в IIS, которые используют эти протоколы, должны зависеть от того, что отличается от ключа сеанса, предоставленного WCF, для сопоставления состояния уровня приложения (например, конструктора уровня приложений или пользовательского заголовка корреляции) или отключения перезапуска процессов IIS для размещенного приложения.
Оптимизация производительности в сценариях среднего уровня
Для оптимальной производительности в сценарии среднего уровня — служба, которая вызывает другие службы в ответ на входящие сообщения, создает экземпляр клиента службы WCF в удаленную службу один раз и повторно использует его в нескольких входящих запросах. Создание экземпляров клиентов служб WCF является дорогостоящей операцией относительно вызова службы в предварительно существующем экземпляре клиента, а сценарии среднего уровня позволяют повысить производительность путем кэширования удаленных клиентов по запросам. Клиенты служб WCF являются потокобезопасными, поэтому не требуется синхронизировать доступ к клиенту в нескольких потоках.
Увеличение производительности в сценариях среднего уровня обеспечивается также благодаря использованию асинхронных интерфейсов API, создаваемых параметром svcutil /a. Этот /a параметр приводит к томуBeginXXX/EndXXX, что средство служебной программы метаданных ServiceModel (Svcutil.exe) создает методы для каждой операции службы, что позволяет потенциально длительным вызовам удаленных служб выполняться в фоновых потоках.
WCF в многосетевых сценариях и сценариях со многими именами
Вы можете развернуть службы WCF в веб-ферме IIS, где набор компьютеров совместно использует общее внешнее имя (например http://www.contoso.com), но по отдельности решается различными именами узлов (например, http://www.contoso.com может направлять трафик на два разных компьютера с именем http://machine1.internal.contoso.com и http://machine2.internal.contoso.com). Этот сценарий развертывания полностью поддерживается WCF, но требует специальной настройки веб-сайта IIS, в котором размещаются службы WCF, для отображения правильного (внешнего) имени узла в метаданных службы (язык описания веб-служб).
Чтобы убедиться, что правильное имя узла отображается в wcF метаданных службы, настройте удостоверение по умолчанию для веб-сайта IIS, на котором размещаются службы WCF для использования явного имени узла. Например, компьютеры, находящиеся в www.contoso.com ферме, должны использовать привязку сайта IIS *:80:www.contoso.com для HTTP и *:443:www.contoso.com для HTTPS.
Привязки веб-узла IIS можно настроить с помощью оснастки консоли управления (MMC) IIS.
Пулы приложений, работающие в разных контекстах пользователей, которые перезаписывают сборки из других учетных записей во временной папке
Чтобы пулы приложений, работающие в разных контекстах пользователей, не могли перезаписать сборки из других учетных записей в папке временных ASP.NET файлов, используйте разные удостоверения и временные папки для разных приложений. Например, если имеется два виртуальных приложения /Application1 и / Application2, можно создать два пула приложений (A и B) с двумя разными идентификаторами. Пул приложений A может работать под одним идентификатором пользователя (user1), а пул приложений B - под другим идентификатором пользователя (user2). Настройте приложение /Application1 на использование пула A, а приложение /Application2 - на использование пула B.
В Web.config можно настроить временную папку с помощью <system.web/компиляции/@tempFolder>. Для /Application1 оно может быть "c:\tempForUser1" и для application2 может быть "c:\tempForUser2". Предоставьте соответствующее разрешение на запись в эти папки для двух идентификаторов.
В этом случае пользователь user2 не может изменить папку создания кода для приложения /application2 (в папке c:\tempForUser1).
Включение асинхронной обработки
По умолчанию сообщения, отправленные в службу WCF, размещенную в IIS 6.0 и более ранних версиях, обрабатываются синхронно. ASP.NET вызовы WCF в собственном потоке (рабочий поток ASP.NET), а WCF использует другой поток для обработки запроса. WCF удерживает рабочий поток ASP.NET до завершения обработки. В результате обработка запросов выполняется синхронно. Обработка запросов асинхронно обеспечивает большую масштабируемость, так как уменьшает количество потоков, необходимых для обработки запроса — WCF не удерживается на потоке ASP.NET при обработке запроса. Использование асинхронного поведения не рекомендуется для компьютеров под управлением IIS 6.0, так как нет способа регулирования входящих запросов, которые открывают сервер для атак типа "отказ в обслуживании " (DOS). Начиная с версии IIS 7.0, реализовано регулирование параллельных запросов: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0]"MaxConcurrentRequestsPerCpu. Новая система регулирования гарантирует безопасность использования асинхронной обработки. По умолчанию в IIS 7.0 регистрируются асинхронные обработчик и модуль. Если эта функция выключена, то можно вручную включить асинхронную обработку запросов в файле Web.config приложения. Используемые параметры зависят от параметра aspNetCompatibilityEnabled. Если параметр aspNetCompatibilityEnabled установлен в значение false, настройте модуль System.ServiceModel.Activation.ServiceHttpModule, как показано в следующем фрагменте конфигурации.
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="false" />
</system.serviceModel>
<system.webServer>
<modules>
<remove name="ServiceModel"/>
<add name="ServiceModel"
preCondition="integratedMode,runtimeVersionv2.0"
type="System.ServiceModel.Activation.ServiceHttpModule, System.ServiceModel,Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
</modules>
</system.webServer>
Если параметр aspNetCompatibilityEnabled установлен в значение true, настройте модуль System.ServiceModel.Activation.ServiceHttpHandlerFactory, как показано в следующем фрагменте конфигурации.
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
</system.serviceModel>
<system.webServer>
<handlers>
<clear/>
<add name="TestAsyncHttpHandler"
path="*.svc"
verb="*"
type="System.ServiceModel.Activation.ServiceHttpHandlerFactory, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
/>
</handlers>
</system.webServer>