Application pool iis что это

Настройка пула приложений IIS (Windows)

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

После того как вы включите пул приложений, его будут использовать все веб-приложения на ваших сайтах.

Чтобы включить выделенный пул приложений IIS для ваших сайтов:

1. Откройте страницу Сайты и домены >Выделенный пул приложений IIS для ваших сайтов.
2. Нажмите Включить.
3. Укажите максимальное допустимое количество рабочих процессов, обрабатывающих запросы для пула приложений IIS, и период бездействия рабочего процесса (в минутах), после которого его следует завершить.
4. Чтобы ограничить объем ресурсов процессора, который может использовать пул приложений IIS, уберите галочку Без ограничений и укажите число (в процентах) в поле Максимальная загрузка ЦП (%), выберите действие, которое следует выполнить, когда рабочий процесс превысит максимальную загрузку ЦП, и укажите период сброса для наблюдения за использованием процессора в пулах приложений. Когда проходит указанное количество минут с момента последнего сброса, IIS сбрасывает таймеры ЦП для вывода в журнал и периодов ограничения.
5. Выберите нужные опции перезапуска в зависимости от времени или потребления ресурсов, чтобы настроить периодический перезапуск пула приложений IIS и избежать нестабильных состояний, которые могут привести к сбоям, зависаниям и утечкам памяти в приложениях.
6. Нажмите OK.

Чтобы остановить все приложения в пуле приложений:

1. Откройте страницу Сайты и домены >Выделенный пул приложений IIS для ваших сайтов.
2. Нажмите Stop (Остановить).

Чтобы запустить все приложения в пуле приложений:

1. Откройте страницу Сайты и домены >Выделенный пул приложений IIS для ваших сайтов.
2. Нажмите Start (Запустить).

Если у вас есть приложения, для которых характерна утечка памяти или сбои при продолжительной работе, мы рекомендуем периодически их перезапускать.

Чтобы перезапустить все приложения в пуле приложений:

1. Откройте страницу Сайты и домены >Выделенный пул приложений IIS для ваших сайтов.
2. Нажмите Перезапустить.

Чтобы отключить выделенный пул приложений IIS для ваших сайтов:

1. Откройте страницу Сайты и домены >Выделенный пул приложений IIS для ваших сайтов.
2. Нажмите Отключить.

Основы архитектуры 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-запроса.

Рис. 1. HTTP request processing pipeline (IIS 7.x).

Таким образом, 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)

• Администрирование драйвера HTTP.sys.
• Управление рабочими процессами.
• Мониторинг показателей производительности веб-сайтов.

В IIS 7.x функция управления процессами была вынесена в отдельную службу – WAS (см. п.2.3) в целях универсализации архитектуры. Теперь WWW-служба стала по своей сути одним из адаптеров, специализируясь на протоколах HTTP/HTTPS – работа поверх драйвера HTTP.sys. Однако WWW-служба остаётся краеугольным компонентом IIS, поэтому её настройка отличается от настройки адаптеров к другим протоколам (чуть подобнее здесь); она функционирует в том же рабочем процессе, что и WAS, и реализована в той же самой библиотеке (рис. 2).

Рис.2. Рабочий процесс со службами W3SVC и WAS.

• NetTcpActivator для протокола TCP;
• NetPipeActivator для Named Pipes;
• NetMsmqActivator для Message Queuing (ака MSMQ).

Рис. 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 для получения рабочего процесса приложения, которому будет передан запрос для обработки и формирования ответа клиенту.

• Адаптеры прослушивателей (Listener adapters) – специальные службы Windows, работающие с конкретным протоколом и взаимодействующие с WAS для направления запросов к правильному рабочему процессу.
• Собственно WAS. Она ответственна за создание рабочих процессов и управление их временем жизни.
• Исполняемый файл w3wp.exe – шаблон рабочего процесса.
• Менеджер приложений управляет созданием и утилизацией доменов приложений (application domains), которые хостятся внутри рабочего процесса.
• Обработчики протоколов – протоколозависимые компоненты внутри рабочего процесса, ответственные за обмен данными между конкретным адаптером и рабочим процессом. Есть 2 типа обработчиков протоколов: у процесса (process protocol handler — PPH) и у домена приложения (AppDomain protocol handlers — ADPH).

Рис. 4. Компоненты w3wp.exe для взаимодействия с внешними компонентами.

Как отмечалось выше, .NET Framework несёт в себе реализацию компонент для протоколов HTTP/HTTPS (наш любимый ASP.NET), net.tcp, net.pipe и MSMQ. Стеки протоколов HTTP/HTTPS и FTP всё-таки более тесно интегрированы в IIS и ОС, поэтому настройку для нового протокола лучше продемонстрировать на примере менее популярных дотнетовских протоколов. Итак, после установки фреймворка в файле конфигурации IIS ApplicationHost.config появляется записи:

А соответствующие компоненты 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. Тема эта достойна отдельной статьи, но меня на неё уже, увы, не хватит, судя по всему. Здесь же представлю вашему вниманию лишь общие, ключевые моменты.

Итак, IIS при обработке запроса пропускает его внутри рабочего процесса через последовательность специальных компонент – модулей. Например фильтрация, перенаправление, кэширование, аутентификация, авторизация. Каждый такой модуль ассоциируется с определённым событием, а их последовательность составляют событийную модель обработки запросов. Модули делятся на нативные (Native) и управляемые (Managed). Нативные модули поставляются вместе с IIS, а управляемые – в составе .NET Framework (ASP.NET). В общем-то, вы можете управлять ими в определённой степени на уровне конфигурации веб-приложения, но взаимодействовать из кода своего 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-приложение.

Более важным с практической точки зрения является то, что приложение/домен приложения является sandbox-ом для кода вашего ASP.NET-сайта (не с такой надёжной изоляцией, как в случае с пулом, но всё же). Приведу один из моих любимых вопросов, которые я задавал соискателям на собеседованиях. Пусть имеются веб-сайт-1 и веб-сайт-2, а также некая библиотека MyLib.dll, в которой определён класс MyClass1 со статическим полем Field1. Итак, оба сайта работают под управлением одного пула приложений и используют одну и ту же библиотеку MyLib.dll. Веб-сайт-1 записывает в MyClass1.Field1 = 16 (рис. 7). Вопрос: увидит ли веб-сайт-2 сделанные изменения? Напрашивается ответ «Нет». Но почему? Потому что, для IIS-приложений выделяются непересекающиеся адресные пространства, даже если они работают внутри единого рабочего процесса, поэтому в память веб-приложений загружаются свои копии сборок (прошу не придираться к возможным неточностям в терминах работы с памятью в .NET Framework).

Рис. 7. Рисунок для задачки.

Ещё один важный момент, который хотелось бы здесь отметить. По умолчанию каждый отдельный рабочий процесс может использовать все имеющиеся на сервере процессоры/ядра, а пул приложений работает на одном рабочем процессе и, следовательно, веб-приложение работает внутри одного IIS-приложения. Тем не менее, вы можете настроить web garden, увеличив кол-во рабочих процессов на пул и, следовательно, число IIS-приложений на одно веб-приложение. Вы без труда сможете найти на просторах интернета информацию о web garden, поэтому опускаю здесь подробности. Единственное, хотелось бы предупредить, что данное средство не является инструментом увеличения производительности, т.к. по умолчанию и так используются все вычислительные мощности сервера. Наоборот, на синхронизацию работы 2+ рабочих процессов уходил «лишнее» время CPU. Делается это в основном для увеличения доступности веб-приложения. Нельзя здесь также не упомянуть о веб-ферме (web farm), как о простейшем средстве балансировки нагрузки в IIS – об этом тоже достаточно статей в Сети. Это другой пример распределённого веб-приложения. Впрочем, с тем же nginx встроенная балансировка нагрузки в IIS конкуренции не выдерживает, и в реальных высоконагрузочных системах вам придётся изобретать свой велосипед или задействовать продукты сторонних производителей.

3. Что дальше?

Дальше нужно разбираться в работе модулей (в терминах IIS) и событийной модели, в которых уже происходит собственно обработка запроса, о чем упоминалось в разделе 2.4. Вообще говоря, эта тема заслуживает отдельной статьи, на которую, боюсь, меня уже не хватит. Но без этого нельзя сказать, что мы рассмотрели весь конвейер обработки запросов. Поэтому кратко пройдёмся здесь по основным моментам, которые любопытствующий читатель может проработать самостоятельно.

Как отмечалось выше в разделе 2.4 модули IIS содержатся внутри рабочего процесса. Через них последовательно пропускается запрос (в отличие от HttpHandler-ов). Их набор и порядок определяется конфигурацией сервера и/или конкретного веб-приложения. Модули предназначены для отдельных, узконаправленных задач, таких как авторизация, кэширование, кастомное логгирование, сжатие, возврат статического контента и, конечно же, формирование HTML-страниц по заданному URL.

Как мы уже знаем, модули в IIS бывают 2 типов: нативные и управляемые. Точный список модулей вы можете почерпнуть в MSDN-е или в статье Риган Темплин. Вы всегда можете написать свой модуль, например, для редиректов. Чаще всего, конечно, делают управляемые модули, т.к. их проще всего реализовать. К слову, ASP.NET WebForms и MVC работают в виде таких вот управляемых модулей. Т.ч. лично у меня холивары WebForms vs. MVC вызывают улыбку и трудно сдерживаемое желание потроллить. Зная принципы работы IIS и ASP.NET, вы сами сможете реализовать любой понравившийся вам паттерн.

На следующем уровне рассмотрения мы столкнёмся уже с составляющими ASP.NET, такими как HttpHandler-ы и события обработки страницы. Про это написана масса статей, т.ч. не вижу смысла сколько-нибудь задерживаться на этом. Единственное, позволю себе посоветовать идущим на собеседования забить в поисковике «ASP.NET page lifecycle» перед встречей – этого уж точно по моему глубокому убеждению стыдно не знать специалистам, считающих себя разработчиками на ASP.NET.

Параметры IIS

Пулы приложений – это новая функция Windows Server 2003, которая изолирует группу приложений в рамках общего набора рабочих процессов и параметров. Изолируя приложения в пулы приложений, вы можете перезапускать рабочие процессы , не влияя на другие пулы приложений сервера. Вместо настройки параметров в разделе файла machine.config вы будете настраивать их в каждом пуле приложений сервера.

Управление пулами приложений

Для быстрого создания и удаления пулов приложений на сервере используйте инструмент администрирования IIS. Ниже приведена процедура добавления к серверу нового пула приложений.

1. Щелкните правой кнопкой мыши на директории Application Pool .
2. Щелкните на New (Создать), а затем на Application Pool (Пул приложений).
3. Укажите имя пула приложений и выберите вариант создания с параметрами по умолчанию или использование в качестве шаблона другого пула приложений, как показано на рис. 8.4.

Рис. 8.4. Введите имя пула приложений и выберите параметры по умолчанию

Будет создан новый пул приложений, вы можете его настраивать и добавлять в него новые приложения.

Настройка пулов приложений

Пулы приложений имеют большое количество параметров для настройки поведения рабочих процессов пула. Чтобы получить доступ к этим параметрам, щелкните правой кнопкой мыши на пуле приложений и выберите пункт Properties (Свойства). Появится диалоговое окно Default AppPool Properties (Свойства AppPool по умолчанию), показанное на рис. 8.5.

Рис. 8.5. Вкладка Recycling (Перезапуск) диалогового окна свойств пула приложений

Данная вкладка содержит параметры, управляющие «переработкой» рабочих процессов (см. табл. 8.1).

Таблица 8.1. Параметры вкладки Recycling (Перезапуск)

Параметр	Описание
Recycle worker processes (in minutes) (Перезапускать рабочие процессы через [мин])	Указывает, что рабочие процессы будут автоматически очищаться каждые Х минут, где Х – число, введенное в текстовом поле.
Recycle worker process (number of requests) (Перезапускать рабочие процессы [число запросов])	Указывает, что каждый рабочий процесс будет автоматически очищаться после того, как обработает Х запросов, где Х – число запросов, введенное в текстовом поле.
Recycle worker processes at the following times (Перезапускать рабочие процессы в указанное время)	Указывает, что рабочие процессы будут автоматически очищаться при наступлении заданного в текстовом поле времени. Это очень полезно, если вы знаете, когда ожидается снижение нагрузки на ваше приложение, чтобы рабочий процесс был очищен, не создавая при этом неудобств пользователям.
Maximum virtual memory (in megabytes ) (Максимальное количество виртуальной памяти, в Мб)	Указывает, что каждый рабочий процесс, использующий виртуальной памяти больше заданного здесь значения, будет автоматически очищен.
Maximum used memory (in megabytes ) (Максимальный размер используемой памяти, в Мб)	Указывает, что каждый рабочий процесс, использующий физической памяти больше заданного здесь значения, будет автоматически очищен.

Эти параметры гарантируют, что ни один процесс не заберет себе все ресурсы памяти сервера. Они также используются для периодического перезапуска процессов, которые могут приводить к утечкам памяти или захватывают слишком много памяти.

Вкладка Performance (Производительность) диалогового окна свойств пула приложений содержит параметры, управляющие производительностью пула приложений и запущенных в нем рабочих процессов (рис. 8.6).

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

Вкладка Health (Работоспособность) диалогового окна свойств пула приложений содержит параметры, относящиеся к состоянию рабочего процесса (рис. 8.7).

Рис. 8.6. Вкладка Performance (Производительность)

диалогового окна свойств пула приложений

C# Разработка

Инициализация приложения IIS должна начинаться сразу после запуска или перезапуска Application Pool. Тем самым вы повысите качество обслуживания первых клиентов, если ваше приложение требует какой то инициализации перед началом обслуживания. Данный способ не использует сторонние сервисы и приложения.

Шаг 1. Установка Application Initialization.

Необходимо убедиться, что у вас установлен Application Initialization. Описание и его настройку на английском языке можно найти по ссылке IIS 8.0 Application Initialization. Статья, по которой я изначально учился настраивать, расположена по адресу Configure the IIS Application Initialization module. Тут же я опишу все шаги на русском языке и не залезая в файлы конфигурации IIS Server.

Для начала надо понять какая у вас стоит версия IIS, для этого можно воспользоваться таблицей:

Версия IIS	Операционные системы
1.0	Windows NT 3.51
2.0	Windows NT 4.0
3.0	Пакет обновления 3 для Windows NT 4.0
4.0	Пакет Option Pack для Windows NT 4.0
5.0	Windows 2000
5.1	Windows XP Professional
6.0	Windows Server 2003
7.0	Windows Vista; Windows Server 2008
7.5	Windows 7; Windows Server 2008 R2
8.0	Windows 8; Windows Server 2012
8.5	Windows 8.1; Windows Server 2012 R2
10	Windows 10; Windows Server 2016

IIS 7.0 и ниже — не поддерживается этим модулем.

IIS 7.5 — переходим по ссылке Application Initialization Module for IIS 7.5 и снизу скачиваем установщик и устанавливаем под разрядность вашей операционной системы.

• x86 for Windows 7
• x64 for Windows 7 or Windows Server 2008 R2

Если вы пользовались Web Platform Installer для установки этого модуля и получили ошибку: IISCA ExecuteInstallWindowsHotfixCA : Error in function InstallWindowsHotfixQuietly, hr=0x80070643 , тогда вам перед установкой нужно включить Windows Update службу и попробовать снова

IIS 8.0, 8.5 и 10 — данный модуль уже установлен и вам достаточно только его включить. Если вы используете серверную операционную систему, тогда вам необходимо отрыть настройки ролей и там поставить галку напротив Application Initialization:

Если вы используете клиентскую операционную систему, тогда необходимо перейти в окно «Установка и удаление программ» и выбрать там «Добавление удалений компонентов Windows«.

Шаг 2. Требуемые параметры.

1. startMode = «AlwaysRunning» говорит о том, что W3WP.exe должен запускаться автоматически, и даже если вы его «убьёте» через диспетчер задач, то он сразу пере запустится. Данный процесс как раз таки и будет в последующем хостить указанные в IIS для него приложения. Но не стоит радоваться, что теперь все работает, потому что сам процесс будет занимать какие то ничтожные несколько мегабайт, и вам все равно придётся делать первый вызов, пока не укажите второй параметр.
2. preloadEnabled =»True» — теперь сразу после запуска процесса W3WP.exe, ваше приложение начнёт процесс инициализации как при первом обращении.

Шаг 3. Настройка startMode=»AwaysRunning» в IIS.

1. Открываем Configuration Editor выделив сверху свой сервер.

2. В Section выбираем system.applicationHost/applicationPools.

3. Выделяем строку (Collection), далее справа появится кнопка с троеточием. Нажимаем на неё.

4. В появившемся окне СНАЧАЛА выбираем ваш Application Pool сверху, затем снизу выбираем startMode -> AlwaysRunning. Закрываем окно Collection Editor.

5. Обязательно! Не забудьте нажать на кнопку «Сохранить«.

Шаг 4. Настройка preloadEnabled=»True» в IIS.

1. В разделе Section выбираем system.applicationHost/sites.

2. Выделяем строку (Collection) далее справа нажимаем на кнопку с троеточием.

3. Первым делом надо выбрать сверху ваш сайт, затем в свойствах найти applicationDefaults, раскрыть его и в свойстве preloadEnabled выставить True.

4. Обязательно! Не забудьте нажать на кнопку «Сохранить«.

Шаг 5. Проверка.

Необходимо перезапустить Application Pool и заметить, что его инициализация должна начаться сразу после запуска. А если процесс W3WP.exe убить из диспетчера задач, то он сразу запустится заново и начнёт снова инициализацию.

В: Как понять, какое приложение запущено в процессе W3WP.exe.

О: Я пользуюсь утилитой Process Explorer. Для того, что бы понять что размещено на конкретном процессе достаточно подвести мышку к процессу и во всплывающем окне можно заметить название сайта у параметра -ap.

Пример:

В: Process Explorer показывает «Отказано в доступе«, что делать?
О: Самый простой способ решения это запуск Application Pool от имени какого то пользователя, а не Network Service. Для этого в «Application Pools» выбираем наш пул и жмём «Advanced Settings» и в поле Indentity выбираем учетную запись, после чего пере запускаем пул.