You can choose to use the default application pool provided by IIS on install, or you can create your own application pool. You can run as many application pools on your IIS 7 and later server as you need, though this can affect server performance. Application pools can contain one or more worker processes. Each worker process represents work being done for a Web site, Web application, or Web service. You can create a Web garden by enabling multiple worker processes to run in a single application pool.
New in IIS 7.5 and later
Starting in IIS 7.5, you can configure an application to start automatically by using the managedRuntimeLoader, CLRConfigFile, and startMode attributes of the element. These attributes configure, respectively, the name of the managed DLL that provides runtime loading for your application, the common language runtime configuration file for the application, and the startup type for the application.
Also new in IIS 7.5 and later is a new ApplicationPoolIdentity type for the identityType attribute of the
element. This new identity type is now the default process identity for applications, and makes it possible to set the security for your content areas to allow access for a specific application pool. To do so, you would set your security using the name of an application pool by using syntax like «IIS AppPool\DefaultAppPool.» This identity is created dynamically, thereby dramatically reducing the surface attack area of your server.
После развертывания сайтом можно управлять с применением средств IIS. Ниже рассматриваются наиболее полезные опции конфигурирования и способы их использования.
Создание нового сайта
IIS 8 может поддерживать множество сайтов на одном сервере. В рассмотренных примерах развертывания содержимое добавлялось к сайту по умолчанию, а в этом разделе будет показано, как создать совершенно новый сайт. Разверните древовидное представление в IIS Manager, щелкните правой кнопкой мыши на узле Sites (Сайты) и в контекстном меню выберите пункт Add Web Site. (Добавить веб-сайт. ). Откроется диалоговое окно Add Web Site, показанное на рисунке ниже:
Поле Site name (Имя сайта) должно содержать что-нибудь значащее. Оно используется для идентификации сайта в среде IIS Manager, но не влияет на содержимое сайта. В этом примере пул приложений был оставлен без изменений (пулы приложений рассматриваются далее). Поле Physical path (Физический путь) определяет местоположение, в котором IIS 8 будет искать содержимое для запросов на обслуживание, адресованных новому сайту. В этом примере на сервере был создан новый каталог D:\WebSites. Кнопки Connect as. (Подкл. как. ) и Test Settings. (Тест настроек. ) позволяют указать другие учетные данные пользователя для доступа к содержимому сайта.
Раздел Bindings (Привязка) позволяет указать, как IIS 8 будет прослушивать запросы, поступающие от клиентов. IIS 8 поддерживает множество протоколов, но мы сосредоточим внимание на HTTP, поскольку он используется наиболее широко. Для этого в списке Type (Тип) выберем опцию http.
Создание виртуальных каталогов
При установке места назначения для примеров веб-сайтов содержимое помещается в каталог, в котором IIS 8 ищет содержимое по умолчанию. Но содержимое можно было бы разместить где-то в другом месте, а затем использовать виртуальный каталог для ссылок на него. Чтобы продемонстрировать этот подход, создадим на сервере новый каталог и скопируем в него содержимое сайта. Путь к новому каталогу выглядит следующим образом:
Чтобы связать новый каталог с IIS, откройте IIS Manager, разверните древовидное представление, щелкните правой кнопкой мыши на элементе Default Web Site и в контекстном меню выберите пункт Add Virtual Directory (Добавить виртуальный каталог). В результате откроется диалоговое окно Add Virtual Directory (Добавление виртуального каталога), показанное на рисунке ниже:
Чтобы протестировать его, откройте браузер на сервере и направьте его на URL-адрес http://localhost/virtual. Как и ранее, откроется созданный нами простой веб-сайт, но на этот раз содержимое будет извлекаться из нового каталога, а доступ к нему будет осуществляться с помощью указанного специального URL-адреса.
Использование пулов приложений
Пулы приложений позволяют для упрощения конфигурирования и управления группировать вместе аналогичные или связанные приложения. При этом приложения, которые включены в пулы приложений, изолируются, в результате чего проблемы, возникающие в одном пуле, не оказывают влияния на приложения из других пулов.
Характеристики пулов приложений, отображаемые в главном окне IIS Manager
Столбец
Описание
Name (Имя)
Определяет имя пула приложений. После того как пул создан, его имя изменить нельзя
Учетная запись Windows, используемая для запуска приложений пула
Количество приложений, назначенных в пул; на рисунке выше видно, что пул DefaultAppPool содержит три приложения
Создание нового пула приложений
Нестандартный пул приложений можно создать, щелкнув на действии Add Application Pool (Добавить пул приложений) в правой части экрана IIS Manager. Откроется диалоговое окно Add Application Pool (Добавление пула приложений), показанное на рисунке ниже:
Щелкните на кнопке OK, и новый пул будет создан и добавлен в список IIS Manager. Щелчок на действии Advanced Settings. (Дополнительные параметры) позволит сконфигурировать детали, связанные с пулом.
Назначение приложения в пул приложений
Чтобы назначить приложение в пул приложений, выберите приложение в окне IIS Manager и щелкните на действии Basic Settings (Основные настройки) в правой части экрана. Откроется диалоговое окно Edit Application (Изменение приложения). Щелкните на кнопке Select (Выбрать) и выберите пул приложений из раскрывающегося списка, как показано на рисунке ниже. Мы выбрали специальный пул приложений, созданный в предыдущем разделе:
Запуск и останов пула приложений
После щелчка на пуле приложений в правой части окна IIS Manager в разделе Application Pool Tasks (Задачи пула приложений) отобразятся три действия. Действия Start (Начало) и Stop (Остановить) определяют то, обслуживаются ли запросы, адресованные назначенным в пул приложениям. Если пул остановлен, клиенты будут получать сообщение об ошибке. Действие Recycle (Перезапуск) переустанавливает пул приложений. Это полезно для устранения постепенно накапливающихся и трудных для диагностирования проблем.
Использование параллельного выполнения
Пулы приложений позволяют на одном сервере запускать приложения, которые требуют различных версий ASP.NET. При использовании унаследованных приложений или постепенной модернизации приложений до ASP.NET 4 можно формировать различные пулы приложений для обеспечения того, чтобы каждое приложение работало с требуемыми функциональными средствами.
Каждый пул приложений в IIS использует свой собственный рабочий процесс (IIS Worker Process). Удостоверение пула приложений (Application Pool Identities) представляет из себя имя учетной записи, под которой выполняется рабочий процесс этого пула.
В IIS 6.0 и IIS 7.0 пул приложений по умолчанию работал под встроенной системной учетной записью NetworkService. Эта запись не требует пароля и имеет на локальном компьютере ограниченные права, что является хорошей практикой с точки зрения безопасности. Однако под этой учетной записью могут одновременно работать разные системные службы Windows, и при использовании одного и того же идентификатора одни службы могут воздействовать на работу других.
Начиная с Windows Server 2008 SP2 для того, чтобы изолировать рабочие процессы IIS от других системных служб, можно использовать виртуальные учетные записи (Virtual Accounts). Они позволяют запускать рабочий процесс для каждого пула приложений под собственной уникальной учетной записью ApplicationPoolIdentity. Эта учетная запись не требует управления и создается автоматически при создании каждого нового пула. Также она не имеет практически никаких привилегий в системе и не использует профиль пользователя, что повышает безопасность веб-сервера.
Для примера возьмем Application Pool с именем PubSite1. Открываем Task Manager и находим рабочий процесс IIS (w3wp.exe), выполняющийся от имени PubSite1. Как видите, имя учетной записи совпадает с именем пула приложений. Дело в том, что начиная с IIS 7.5 для каждого вновь созданного пула приложений по умолчанию создается виртуальная учетная запись с именем этого пула, и его рабочий процесс запускается из под этой записи.
Настройка типа удостоверения пула приложений
При необходимости тип идентификации пула приложений можно изменить. Для этого запускаем IIS Manager, переходим в раздел Application Pools, выбираем нужный пул и открываем его свойства (Advanced Settings).
В свойствах выбираем пункт Identity.
Здесь мы указываем учетную запись, от имени которой будет работать данный пул приложений:
• ApplicationPoolIdentity — учетная запись удостоверения пула приложений. Создается автоматически при запуске пула приложений и имеет самые минимальные права на локальном компьютере. Это наиболее безопасный вариант, начиная с IIS 7.5 используется по умолчанию; • LocalService – встроенная учетная запись, которая имеет ограниченные права на локальном компьютере. Примерно то же самое, что и NetworkService, но ограничена только локальным компьютером; • LocalSystem – системная учетная запись, имеющая неограниченные права на локальном компьютере. Наименее безопасный вариант, по возможности не рекомендуется ее использовать; • NetworkService — учетная запись, которая имеет ограниченные права на локальном компьютере, а также может использоваться для доступа к ресурсам в сети Active Directory на основании учетной записи компьютера.
Кроме того, в качестве удостоверения можно использовать и обычную учетную запись пользователя. Для этого надо выбрать Custom Account, нажать кнопку Set и ввести имя пользователя и пароль. Можно указать любого доменного или локального пользователя.
Примечание. При использовании учетной записи пользователя надо отслеживать срок действия пароля и своевременно менять его.
То же самое можно сделать с помощью утилиты командной строки appcmd. Чтобы указать учетную запись, которая будет использоваться для пула приложений, используется следующий синтаксис:
appcmd set config /section:applicationpools /[name=″имя пула приложений″].processModel.identityType:SpecificUser|NetworkService|LocalService|LocalSystem
Для примера изменим тип удостоверения для пула приложений PubSite1 на NetworkService:
appcmd set config /section:applicationpools /[name=″PubSite1″].processModel.identityType:NetworkService
Профиль пользователя
Если вы хотите настроить ApplicationPoolIdentity на использование пользовательского профиля, то надо зайти в расширенные свойства пула и перевести параметр Load User Profile в состояние True.
Настройка доступа к ресурсам
Иногда веб-приложению может потребоваться доступ к определенной папке или файлу на диске. Чтобы добавить ApplicationPoolIdentity в Access Control List (ACL):
• Запускаем Windows Explorer; • Выбираем нужный файл или директорию, кликаем по ней правой клавишей мыши и выбираем пункт Свойства (Properties); • Переходим на вкладку Безопасность (Security), • Кликаем по кнопке Изменить (Edit), затем Добавить (Add); • В поле Размещение (Locations) выбираем локальную машину; • Вводим имя пользователя в виде ″IIS AppPool\имя пула приложений″. Так для пула приложений PubSite1 имя пользователя будет выглядеть ″IIS AppPool\PubSite1″; • Проверяем имя клавишей Проверить имена (Check Names) и жмем ОК.
Также при желании можно воспользоваться утилитой командной строки ICACLS. Для примера дадим права на изменение для PubSite1:
D – удаление; F – полный доступ; M – изменение; RX – чтение и выполнение; R – чтение; W – запись.
Если ресурс находится в сети, то для доступа к нему лучше всего использовать учетную запись NetworkService. Рабочий процесс, запущенный под этим аккаунтом, для доступа к ресурсам использует учетные данные компьютера, сгенерированные при добавлении компьютера в домен. Для того, чтобы дать процессу доступ к сетевому ресурсу, в качестве пользователя указываем компьютер:
• Выбираем тип объекта (Object Type) Computers; • В поле Размещение (Locations) выбираем домен; • Вводим имя пользователя в виде domainname\machinename$, например contoso\SRV12$; • Проверяем имя и жмем ОК.
Очень удобный способ предоставлять доступ к сетевым ресурсам типа файловых шар или баз данных SQL Server. Однако работает он только при наличии домена AD.
Основы архитектуры IIS, или запросопровод для ASP.NET
В прошлом году мне пришлось отсобеседовать около 10-15 кандидатов на должность веб-программиста на ASP.NET средней квалификации. В качестве вопросов «на засыпку», или «со звёздочкой», я просил рассказать, что происходит с HTTP-запросом от момента его поступления на 80-й порт сервера до передачи управления коду aspx-страницы. Статистика была удручающей: ни один из кандидатов не смог выдать хоть что-нибудь внятное. И этому есть своё объяснение: ни в MSDN с technet, ни на специализированном ресурсе iis.net, ни в книгах a-la «ASP.NET для профессионалов», ни в блогах данной теме не уделяется должного внимания – информацию приходится собирать чуть ли не по крупицам. Я даже знаю людей, которые решили написать свой собственный веб-сервер (Игорь, Георгий, привет!), чтобы не разбираться в работе IIS. Единственная толковая статья – «Introduction to IIS Architectures» Риган Темплин (Reagan Templin). Но и она остаётся на периферии интересов аспнетчиков.
Хотя мне лично уже не так интересны чисто технические вопросы, я решил собрать в кучу свой накопленный опыт, раскопать на просторах Сети любопытные детали и передать сие сакральное знание массам, пока оно ещё не устарело. Сразу оговорюсь, что статья ориентирована в большей степени на IIS 7.x, иногда будут ответвления про 6-ку. С 8-й версией в работе не сталкивался, поэтому решил обойти её в этой статье стороной. Но, уверен, читатель без труда разберётся с восьмёркой, освоив изложенный ниже материал.
1. Общий план 2. Крупный план 2.1. HTTP.SYS 2.2. World Wide Web Publishing Service (W3SVC) 2.3. Windows Process Activation Service (WAS) 2.4. Пул приложений 2.5. Домен приложения, приложение 3. Что дальше? Источники
1. Общий план
Итак, начнём с конца, а потом рассмотрим отдельные аспекты чуть более пристально. В англоязычной литературе процесс обработки запроса в IIS называется «request processing pipeline» — что-то вроде «конвейера обработки запроса». В общих чертах он представлен на рисунке ниже для http-запроса.
Таким образом, http-запрос проходит по «сборочной ленте конвейера» через следующее:
1. Браузер обращается к веб-серверу по определённому URL, на стороне сервера запрос перехватывает драйвер HTTP.SYS. 2.HTTP.SYS стучится к WAS для получения информации из хранилища конфигурации. 3. Служба WAS запрашивает конфигурацию из хранилища — из файла в папке IIS (applicationHost.config). 4. Поскольку данный запрос получен по протоколу HTTP конфигурационную информацию получает служба W3SVC (она же WWW Service на картинке), эта информация содержит в себе данные о пуле приложений (application pool) и прочих параметрах сайта. 5. Служба W3SVC использует эту информацию для кофигурации HTTP.SYS. 6. Служба WAS запускает процесс W3WP.exe для пула приложений, если он ещё не был запущен. 7. В процессе W3WP.exe работает приложение веб-сайта, которое, собственно, формирует и возвращает ответ драйверу HTTP.SYS. 8.HTTP.SYS отправляет ответ браузеру.
В принципе уже этой схемы достаточно для прохождения интервью в большинстве компаний и получения общего представления об архитектуре IIS. Но если вы не для галочки сюда зашли, то прошу следовать далее.
2. Крупный план
2.1. HTTP.SYS
На транспортном уровне IIS использует прослушивателей протоколов (protocol listeners), которые располагаются поверх стека TCP/IP. Наиболее интересный нам такой компонент – это системный драйвер HTTP.sys, который встроен в ядро ОС и работает с протоколами HTTP и HTTPS, регистрирующийся самостоятельно на прослушку всех портов, на которые будут приходить запросы к сайтам в IIS.
Встроенный в ядро HTTP.sys стал нововведением в IIS 6, заместив собой Windows Socket API – компонент перехвата HTTP- и HTTPS-запросов на пользовательском уровне в IIS более ранних версий. Вероятно, интеграция драйвера в ядро является той самой причиной, по которой версия IIS жёстко привязана к версии Windows.
Драйвер принимает все входящие запросы и перенаправляет их в нужный пул приложений. Если по какой-то причине рабочий процесс, в коем хостится требуемый пул, остановлен (сбой, таймаут простоя, смена конфигурации и т.п.) или ещё запускается, то HTTP.sys сохраняет входящие запросы в специально отведённой для каждого пула очереди. Таким образом, запросы пользователей никуда не пропадают, и они вообще не замечают каких-то перебоев в работе сайтов под управлением IIS.
Ещё HTTP.sys умеет кешировать ответы (более подробно — Instances in which HTTP.sys does not cache content), поэтому некоторые запросы обрабатываются без передачи на уровень приложения, а также проводит первичный разбор URI запроса и его валидацию в соответствии с RFC 2396 (кое-что можно почерпнуть отсюда — Use of special characters like ‘%’ ‘.’ and ‘:’ in an IIS URL) и журналирование запросов/ответов.
Некоторые настройки HTTP.sys вынесены в системный реестр Windows (более подробно — Http.sys registry settings for Windows). Кстати, там же – в реестре – можно подсмотреть обычное место прописки нашего гражданина: %SystemRoot%\system32\drivers\http.sys.
Признаться, в процессе написания данной статьи я сам открыл для себя некоторые детали. Например, кэширование ответов на уровне драйвера HTTP.sys. Это помогло мне объяснить один случай странного, как мне тогда казалось, феномена в поведении IIS. Маркетологи выложили на сайт swf-открытку перед очередным праздником, но потом им что-то не понравилось в названии файла и они его переименовали. Однако сайт продолжал выдавать открытку по старому URL и даже очистка браузерного кэша не помогала. Тут уже подключился я, но ни перезапуск веб-сайта и всего пула приложений, ни обращение к сайту в обход корпоративного прокси-сервера не дали ожидаемого результата. Но теперь-то мы знаем, кто виноват.
2.2. World Wide Web Publishing Service (W3SVC)
В IIS 7.x функция управления процессами была вынесена в отдельную службу – WAS (см. п.2.3) в целях универсализации архитектуры. Теперь WWW-служба стала по своей сути одним из адаптеров, специализируясь на протоколах HTTP/HTTPS – работа поверх драйвера HTTP.sys. Однако WWW-служба остаётся краеугольным компонентом IIS, поэтому её настройка отличается от настройки адаптеров к другим протоколам (чуть подобнее здесь); она функционирует в том же рабочем процессе, что и WAS, и реализована в той же самой библиотеке (рис. 2).
Рис.2. Рабочий процесс со службами W3SVC и WAS.
Рис. 3. Перечень стандартных не-HTTP-адаптеров в оснастке Служб Windows.
Но всё-таки наиболее важным для нас адаптером является именно WWW-служба, т.ч. остановимся чуть подробнее на двух оставшихся от IIS 6 функциях.
Администрирование и конфигурирование HTTP(S). В момент обновления конфигурации веб-сайтов, служба WAS передаёт эту информацию WWW-службе, а та уже, в свою очередь, настраивает HTTP.sys на прослушку конкретных портов, разбор IP и заголовка запрашиваемого сайта и, возможно, других параметров драйвера. В обратную сторону W3SVC обращается к WAS, когда в очередь запросов в HTTP.sys поступает новый, – для получения рабочего процесса-обработчика данного запроса.
Отслеживание показателей производительности. WWW-служба ведёт счётчики производительности, используя для этого драйвер HTTP.sys, и предоставляет их показатели веб-сайтами и кэшу IIS. Более подробной информации по этому вопросу мне найти не удалось.
2.3. Windows Process Activation Service (WAS)
Итак, WWW-служба в IIS 7.x, как и в IIS 6, продолжает выполнять задачи по администрированию HTTP.sys и управлению показателями производительности веб-сайтов. А вот задача управления рабочими процессами вынесена в отдельную службу – WAS. Она запускается системой в единственном экземпляре, считывает конфигурацию из файла %SystemRoot%\System32\inetsrv\Config\ApplicationHost.config и настраивает через соответствующие адаптеры прослушивателей протоколов в соответствии с указанной в нём информации. Напомним, что для протоколов HTTP/HTTPS адаптером является служба W3SVC, а прослушивателем – драйвер HTTP.sys. При перехвате прослушивателем запроса он через свой адаптер обращается к службе WAS для получения рабочего процесса приложения, которому будет передан запрос для обработки и формирования ответа клиенту.
Рис. 4. Компоненты w3wp.exe для взаимодействия с внешними компонентами.
А соответствующие компоненты PPH и ADPH настраиваются в дотнетовском machine.config:
В конфигурационном файле веб-сервера ApplicationHost.config вместе с настройками приложений хранятся связки (bindings), определяющие параметры входящих запросов, которые будут направляться данному приложению. Такими параметрами являются название сетевого протокола, IP-адрес сервера, доменное имя и порт сайта. Эти параметры должны быть уникальными среди работающих приложений для однозначной идентификации целевого приложения. Служба WAS отслеживает это ограничение и не даст вам запустить сайт, у которого это условие не соблюдено, либо предложит остановить сайт с такой же связкой.
Обратите внимание, что в стандартном режиме эксплуатации IIS служба WAS, служба-адаптер для каждого прослушивателя протокола (в т.ч. W3SVC) и сами драйверы/прослушиватели каждого из протоколов (в т.ч. HTTP.sys) запущены в ОС в единственном экземпляре. Но отдельные запросы могут направляться разным приложениям в разных рабочих процессах. С другой стороны, отдельно взятому приложению могут направляться запросы по разным протоколам через соответствующие адаптеры. Видимо, для корректной реализации такого поведения и была придумана архитектурная связка драйвер протокола – адаптер драйвера протокола – служба активации (своеобразный регулировщик, точнее — маршрутизатор) – рабочий процесс.
2.4. Пул приложений
При конфигурации веб-приложения помимо привязок (binding) к параметрам запросов и прочих настроек указывается принадлежность к пулу приложений. Пул приложений стал нововведением в IIS 6 и был призван обеспечить изоляцию веб-приложений друг от друго и тем самым повысить стабильность работы веб-сервера в целом. Суть заключается в том, что код приложения выполняется внутри специального процесса Windows – w3wp.exe. Поэтому исключение внутри веб-приложения приведёт к краху только этого процесса и никак не повлияет на доступность веб-приложений в других пулах и работу служб IIS. Более того, служба WAS попытается заново запустить упавший сайт, и внешние клиенты могут даже не заметить проблем в работе сервера.
Для управления некоторыми параметрами отдельно взятого рабочего процесса w3wp.exe в IIS используется пул приложений. Наиболее часто используемыми из них являются учётная запись, под которой будет запущен процесс, ограничения для очереди запросов, различные таймеры и счетчики для автоматического перезапуска процесса, архитектура x86/x64 (в IIS 7.x) и некоторые другие (рис. 5), о чём любопытный читатель может с лёгкостью прочесть в MSDN и любимом поисковике. Т.о. можно говорить (с определёнными оговорками, см. тж. последний абзац в 2.5) о тождественности процесса w3wp.exe и пула приложений.
Рис. 5 Дополнительные настройки пула приложений
Ключевым нововведением в концепции пулов приложений в IIS 7.x стал новый параметр – модель управления контейнером, который может принимать 2 значения: классическая (Classic mode) и встраиваемая модель (Integrated mode). Чтобы объяснить разницу между этими режимами работы, потребуется знакомство с понятием «модуль» (Module) в IIS 6/7.x и событийной моделью обработки запросов в связке IIS + ASP.NET. Тема эта достойна отдельной статьи, но меня на неё уже, увы, не хватит, судя по всему. Здесь же представлю вашему вниманию лишь общие, ключевые моменты.
Рис. 6. Идеология модулей в IIS.
Классическая модель управления контейнером обеспечивает обратную совместимость с режимом изоляции рабочих процессов в IIS 6 – запросы к ASP.NET-сайту сначала проходят через нативные модули, а затем передаются в Aspnet_isapi.dll для обработки модулями в управляемой среде. Такое разделение между IIS и ASP.NET приводит к дублированию некоторых функций, например, аутентификации и авторизации. И вы не имеете возможности управлять программно поведением нативных модулей (пример хоть и не самый животрепещущий, но всё же – раздел «Убираем заголовок Server» в этой статье).
Встраиваемая модель предполагает более тесное взаимодействие между IIS и ASP.NET. Запрос в такой архитектуре обработки пропускается через установленную последовательность событий, в каждом из которых запрос пропускается через нативный и управляемые модули. В таком режиме модели обработки запросов IIS и ASP.NET объединены в единую модель, что позволяет избежать дублирования функций и получить больший контроль над обработкой запроса.
На практике самое важное, что необходимо учитывать при разработке и развёртывании веб-приложений, – это частичная несовместимость этих двух режимов. Т.е. при переводе сайта (точнее пула приложений, в котором работает сайт) из классической модели во встраиваемую практически всегда потребуется корректировка кода (хоть, возможно, и не значительная), а также тщательное тестирование.
2.5. Домен приложения, приложение
Непосредственными контейнерами веб-приложения являются приложение и домен приложения (Application Domain, AppDomain). Зачастую эти два понятия отождествляются, но всё-таки это немного разные вещи. Приложение – это понятие IIS, а домен приложения – из ASP.NET. Причём в общем случае в приложении может быть несколько доменов. Приложением вы можете управлять из консоли IIS, а доменом приложения – в основном программно. Так, например, перезапускается приложение из консоли. А когда мы пересохраняем web.config, то перезагружается именно домен приложения, не трогая IIS-приложение.
Ещё один важный момент, который хотелось бы здесь отметить. По умолчанию каждый отдельный рабочий процесс может использовать все имеющиеся на сервере процессоры/ядра, а пул приложений работает на одном рабочем процессе и, следовательно, веб-приложение работает внутри одного IIS-приложения. Тем не менее, вы можете настроить web garden, увеличив кол-во рабочих процессов на пул и, следовательно, число IIS-приложений на одно веб-приложение. Вы без труда сможете найти на просторах интернета информацию о web garden, поэтому опускаю здесь подробности. Единственное, хотелось бы предупредить, что данное средство не является инструментом увеличения производительности, т.к. по умолчанию и так используются все вычислительные мощности сервера. Наоборот, на синхронизацию работы 2+ рабочих процессов уходил «лишнее» время CPU. Делается это в основном для увеличения доступности веб-приложения. Нельзя здесь также не упомянуть о веб-ферме (web farm), как о простейшем средстве балансировки нагрузки в IIS – об этом тоже достаточно статей в Сети. Это другой пример распределённого веб-приложения. Впрочем, с тем же nginx встроенная балансировка нагрузки в IIS конкуренции не выдерживает, и в реальных высоконагрузочных системах вам придётся изобретать свой велосипед или задействовать продукты сторонних производителей.
3. Что дальше?
Дальше нужно разбираться в работе модулей (в терминах IIS) и событийной модели, в которых уже происходит собственно обработка запроса, о чем упоминалось в разделе 2.4. Вообще говоря, эта тема заслуживает отдельной статьи, на которую, боюсь, меня уже не хватит. Но без этого нельзя сказать, что мы рассмотрели весь конвейер обработки запросов. Поэтому кратко пройдёмся здесь по основным моментам, которые любопытствующий читатель может проработать самостоятельно.
Как отмечалось выше в разделе 2.4 модули IIS содержатся внутри рабочего процесса. Через них последовательно пропускается запрос (в отличие от HttpHandler-ов). Их набор и порядок определяется конфигурацией сервера и/или конкретного веб-приложения. Модули предназначены для отдельных, узконаправленных задач, таких как авторизация, кэширование, кастомное логгирование, сжатие, возврат статического контента и, конечно же, формирование HTML-страниц по заданному URL.
