Если уровнем изоляции для классического приложения на основе ISAPI-расширения будет выбран High (Высокий). IIS выполнит ISAPI-приложение в отдельном процессе dllhost.ехе. Как уже упоминалось, приложения ASP.NET работают в своем собственном изолированном рабочем процессе. Приложения изолируются с помощью доменов приложений.

Доменами приложений (application domain) являются механизмы CLR для изолирования компонентов .NET, выполняющихся в одном и том же процессе хоста, с целью обеспечения безопасности и надежности. Кроме того, этот рабочий процесс предлагает полностью конфигурируемую модель процессов, которая определяет различные параметры настройки для повышения надежности Web-приложений: параметры настройки включают повторное использование процессов, ограничения на использование памяти рабочими процессами, организацию очередности запросов и многое другое.

В табл. 18.1 перечислены наиболее важные параметры настройки элемента <processModel> в конфигурационном файле machine.config. (Полный список параметров настройки можно найти в документации по элементу <processModel > в MSDN Online.)

Помимо положительных черт у этой модели процессов имеется два существенных недостатка. Во-первых, если происходит сбой в приложении, работающем непосредственно в процессе Web-сервера, это может привести к сбою всего Web-сервера. В связи с этим команда разработчиков IIS, добавила возможность конфигурирования уровней изоляции и выполнения Web-приложений в отдельных процессах, что позволяет решить эту проблему.

Однако, по умолчанию это поведение не относится к приложениям ASP.NET так как они работают во внешнем рабочем процессе ASP.NET (aspnet_wp. ехе). Оно затрагивает лишь классические приложения ASP или любой другой тип ISAPI-расширения (например, PHP, Perl или специальные ISAPI-расширения C++). Чтобы применить это поведение к ASP.NET, нужно запретить модель процессов с помощью элемента <processMedel> в файле machine.config, о чем уже говорилось ранее. Запрещение модели процессов ASP.NET означает, что вы не сможете использовать описанные особенности модели процессов. Более того, это означает, что для каждого процесса потребуется загружать экземпляр CLR. Естественно, следует иметь в виду, что загрузка дополнительных экземпляров CLR влечет за собой расходование дополнительной памяти.

Во-вторых, если внимательно посмотреть на рис. 18.4, то можно заметить, что с моделью процессов связана другая, еще более серьезная проблема. Давайте повнимательнее посмотрим на поток запроса, показанный на рис. 18.4. Вы увидите, что в потоке есть два переключения контекста; первое происходит между сетевым стеком режима ядра и Web-сервером, работающим в режиме пользователя, а второе переключение контекста имеет место между процессом Web-cepвepa и внешним рабочим процессом dllhost.ехе или aspnet_wp.ехе.

Переключения контекста являются дорогими операциями, особенно если процессы работают от имени различных пользователей. При переключении контекста происходит маршализация (marshaling) данных и их обмен между процессами. Чтобы повысить производительность и надежность, команда разработчиков IIS существенно изменила архитектуру IIS с выходом Windows Server 2003, о чем будет сказано в разделе "Модель процессов IIS 6.0" далее в этой главе.

 

предыдущая    следующая страница    вначало главы    оглавление

751