Инициализация приложений IIS 8.0

Шон Эган

Совместимость

Проблема.

Распространенная проблема, с которой сталкиваются администраторы веб-сайтов, — это необходимость выполнять задачи инициализации и "разогрева" для веб-приложения. Более крупные и более сложные веб-приложения могут нуждаться в выполнении длительной обработки при запуске, заполнения кэшей в памяти, создания содержимого и т. д. перед обслуживанием первого HTTP-запроса.

Решение

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

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

Пошаговые инструкции

Необходимые условия

Компонент инициализации приложений требует установки IIS 8.0. Кроме того, необходимо установить функцию инициализации приложений в подфункционале IIS "Разработка приложений".

На следующем снимке экрана пользовательского интерфейса диспетчера сервера Windows Server 2012 показана функция инициализации приложения.

Обходные пути для известных ошибок

• В настоящее время для этой функции отсутствуют известные ошибки.

Инициализация глобальных приложений

Компонент инициализации приложений можно настроить в двух местах: файл applicationHost.config на уровне компьютера и файл web.config уровня приложения. Конфигурация в файле applicationHost.config содержит параметры инициализации глобального приложения, а файл web.config уровня приложения содержит параметры инициализации локального приложения.

В этом пошаговом руководстве вы настроите пример приложения для инициализации при запуске пула приложений, связанного с приложением. Поскольку поведение пула приложений можно настроить только в applicationHost.config, инициализация приложения при каждом запуске пула приложений считается частью параметров "глобальной" инициализации приложений.

Изменения в applicationHost.config

Откройте файл applicationHost.config, находящийся по адресу %WINDIR%\system32\inetsrv\config, в программе Блокнот. (Не забудьте запустить текстовый редактор с параметром "Запуск от имени администратора!")

<Найдите раздел конфигурации applicationPools> и найдите запись пула приложений с именем .NET версии 4.5.

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

<add name=".NET v4.5" startMode="AlwaysRunning" managedRuntimeVersion="v4.0" />

Прокрутите чуть дальше в файле applicationHost.config до элемента конфигурации <sites>. В этом разделе будет указана <application> запись для образца приложения (см. приложение за инструкциями по созданию образца приложения на вашей машине). Приложение называется appinit и имеет значение атрибута пути "/appinit". Измените <application> запись, добавив полужирный атрибут preloadEnabled , как показано в фрагменте конфигурации, а затем сохраните изменения.

<application path="/appinit" preloadEnabled="true" applicationPool=".NET v4.5">

При установке параметра preloadEnabled в значение "true", служба IIS 8.0 отправляет "поддельный" запрос в приложение при запуске связанного пула приложений. Именно поэтому на предыдущем шаге мы задали для пула приложений свойство startMode в значение "AlwaysRunning".

IIS 8.0 обеспечивает, что экземпляр пула приложений всегда работает, и приложение «/appinit» получает фиктивный запрос для запуска, в случае когда пул приложений всегда активен и приложение настроено на постоянное получение фиктивного запроса, либо при перезагрузке компьютера или при сбросе веб-службы.

Изменения в web.config приложения

Используя второй экземпляр Блокнота, откройте файл уровня приложения web.config, расположенный в следующем расположении. (Не забудьте запустить текстовый редактор с параметром "Запуск от имени администратора!")

C:\inetpub\wwwroot\appinit

Примечание. Измените букву диска, если веб-сайт по умолчанию установлен на другом физическом диске.

Файл web.config содержит несколько разделов конфигурации, которые уже заполнены, но закомментированы. Раскомментируйте фрагмент конфигурации, показанный внутри <system.webServer> раздела конфигурации. Этот фрагмент находится под комментарием "Упражнение 1 - Шаг 1" в файле web.config. Затем сохраните изменения.

<applicationInitialization
    remapManagedRequestsTo="Startup.htm" 
    skipManagedModules="true" >
  <add initializationPage="/default.aspx" />
</applicationInitialization>

Элемент applicationInitialization сообщает IIS, что он должен выдавать запрос к корневому URL-адресу приложения (/default.aspx" в этом примере), чтобы инициализировать приложение. Пока IIS ожидает завершения запроса "/default.aspx", он будет обслуживать "Startup.htm" для всех активных клиентов браузера. "Startup.htm" — это страница-заставка для приложения.

Запуск приложения

В окне командной строки с повышенными привилегиями перезапустите веб-службу World Wide Web Service с помощью команды, показанной ниже:

net stop w3svc & net start w3svc

Не забудьте запустить окно командной строки с помощью параметра "Запуск от имени администратора".

Используя Internet Explorer, перейдите по следующему URL-адресу:

http://localhost/appinit/default.aspx

Браузер возвращает статическую веб-страницу "Startup.htm" с серым фоном в первые несколько секунд, так как это "страница-заставка", настроенная в web.config. Вы можете продолжить обновление страницы в веб-браузере и наблюдать, что примерно через восемь секунд (имитация приостановки потока в файле global.asax в примере приложения) вы получите "реальное" содержимое для default.aspx с белым фоном. Это означает, что инициализация приложения завершена.

Настройка перекрепляемой переработки процессов

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

Вернитесь к экземпляру Блокнота с applicationHost.config. Измените запись пула приложений для '.NET v4.5', чтобы она выглядела следующим образом:

<add name=".NET v4.5"
                startMode="AlwaysRunning"
    managedRuntimeVersion="v4.0" >
  <recycling logEventOnRecycle="Schedule">
    <periodicRestart requests="30" />
  </recycling>
</add>

Не забудьте сохранить изменения!

Элемент <переработки сообщает IIS> о переработке рабочего процесса каждые 30 HTTP-запросов.

Запуск приложения во второй раз

В окне командной строки с повышенными привилегиями перезапустите веб-службу World Wide Web Service с помощью команды, показанной ниже:

net stop w3svc & net start w3svc

С помощью нового экземпляра Internet Explorer снова перейдите по следующему адресу:

http://localhost/appinit/default.aspx

Обратите внимание, что страница "Startup.htm" с серым фоном отображается.

Затем откройте диспетчер задач и убедитесь, что отображается вкладка Процессы. Сортируйте список процессов по имени, пока не увидите один экземпляр w3wp.exe запущен. Этот экземпляр представляет собой рабочий процесс, который в настоящее время выполняет приложение appinit ASP.NET.

Обновите браузер несколько раз, пока не будет возвращено содержимое из реальной default.aspx страницы. Вы понимаете, что приложение загружает настоящую страницу default.aspx, когда фон изменяется на белый. Затем разместите окна на экране, чтобы вы могли видеть диспетчер задач и браузер.

Теперь вернитесь в браузер и обновите страницу не менее 30 раз, это приводит к перезапуску пула приложений IIS. При отображении второго экземпляра w3wp.exe в списке процессов диспетчера задач можно остановить обновление страницы, как показано ниже:

Скриншот показывает, что второй экземпляр w3wp.exe запустился из-за ранее установленного предела утилизации процесса.

Вы можете периодически обновлять окно браузера в течение следующих десяти секунд. Обратите внимание, что default.aspx продолжает работать. После завершения взаимоисключающей переработки один экземпляр w3wp.exe исчезает из окна процессов диспетчера задач.

На протяжении всего периода перекрывающейся утилизации вы продолжаете видеть содержимое "реальных" default.aspx, даже если была настроена инициализация и выполнялся URL-адрес инициализации в фоновом режиме в новом экземпляре w3wp.exe.

Перезапись URL-адресов и инициализация приложений

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

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

Примечание. Сведения об установке переопределения URL-адресов см. в приложении.

Изменения в applicationHost.config

Используя экземпляр Блокнота, в котором открыт файл applicationHost.config, восстановите исходное состояние пула приложений и элементов приложения, чтобы отключить процесс глобальной инициализации приложений. Глобальные параметры удаляются на этом шаге, так как остальная часть этого пошагового руководства фокусируется на настроенном поведении инициализации приложений.

Записи applicationHost.config для пула приложений и приложения, как показано ниже.

Конфигурационная запись пула приложений:

<add name=".NET v4.5" managedRuntimeVersion="v4.0" />

Запись конфигурации приложения:

<application path="/appinit" applicationPool=".NET v4.5">

Не забудьте сохранить изменения после завершения работы!

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

net stop w3svc & net start w3svc

Изменения на уровне приложения web.config

Используя экземпляр Блокнота с открытым файлом web.config на уровне приложения, удалите атрибут remapManagedRequestsTo из элемента <applicationInitialization>. Теперь <applicationInitialization> раздел конфигурации должен выглядеть как этот фрагмент конфигурации.

<applicationInitialization skipManagedModules="true" >
  <add initializationPage="/default.aspx" />
</applicationInitialization>

Поскольку элемент <applicationInitialization> больше не определяет URL-адрес для ремаппинга запросов, добавьте набор правил перезаписи URL. Затем добавьте правило перезаписи, которое явно сопоставляет запросы, сделанные к "default.aspx", а также "/", для направления на "Startup.htm". Требуются два правила, так как модуль перезаписи URL-адресов не знает, как работают документы по умолчанию. Так как значение "/" соответствует "default.aspx" в приложениях ASP.NET, вам потребуется два правила перезаписи URL-адресов — одно правило для каждого варианта URL-адреса.

Новые правила показаны полужирным шрифтом ниже. Кроме того, вы можете раскомментировать предварительно заполненные правила перезаписи URL-адресов под комментарием "Упражнение 2 - Шаг 2. Запросы сопоставления с домашней страницей" в файле web.config.

<rewrite> 
  <rules>
    <rule name="Home Page-Expanded" stopProcessing="true">
      <match url="default.aspx" />
      <conditions>
        <add input="{APP_WARMING_UP}" pattern="1" />
      </conditions>
      <action type="Rewrite" url="Startup.htm" />
    </rule>
    <rule name="Home Page-Short" stopProcessing="true">
      <match url="^$" />
      <conditions>
        <add input="{APP_WARMING_UP}" pattern="1" />
      </conditions>
      <action type="Rewrite" url="Startup.htm" />
    </rule>
  </rules>
</rewrite>

Примечания к этим правилам: во-первых, атрибут stopProcessing установлен на "true" для элементов <правила и>. Это необходимо для добавления общего правила перезаписи URL, а также для запросов к default.aspx или "/", которые не должны запускать общее правило.

Во-вторых, обратите внимание, что у нас есть условие Url Rewrite в элементе <conditions/>. Это условие фактически говорит, что "применяется только правило, если приложение находится в состоянии инициализации". Переменная сервера "APP_WARMING_UP" устанавливается службой IIS значением "1", если инициализация приложения активна, и IIS по-прежнему обрабатывает все URL-адреса инициализации.

Наконец, обратите внимание, что действие было определено для перезаписи активного запроса, чтобы вместо этого запустить "Startup.htm". Это правило имеет эффект передачи запроса обработчику статических файлов, после чего отображается статическая страница Startup.htm.

Затем добавьте универсальное правило перезаписи (catch-all). Когда используется модуль перезаписи URL-адресов вместе с инициализацией приложения, необходимо правило catch-all, которое срабатывает, если ни одно из предыдущих правил не соответствует. Добавьте полужирное правило, показанное ниже, в раздел перезаписи в качестве правила catch-all. Кроме того, вы можете раскомментировать предварительно заполненное правило "catch-all" в web.config, которое находится в разделе "Упражнение 2 - Шаг 2. Настройка правила catch-all" в файле web.config.

<rewrite> 
  <rules>
    <rule name="Home Page-Expanded" stopProcessing="true">
      <match url="default.aspx" />
      <conditions>
        <add input="{APP_WARMING_UP}" pattern="1" />
      </conditions>
      <action type="Rewrite" url="Startup.htm" />
    </rule>
    <rule name="Home Page-Short" stopProcessing="true">
      <match url="^$" />
      <conditions>
        <add input="{APP_WARMING_UP}" pattern="1" />
      </conditions>
      <action type="Rewrite" url="Startup.htm" />
    </rule>
    <rule name="All Other Requests">
      <match url=".*" />
      <conditions>
        <add input="{APP_WARMING_UP}" pattern="1" />
      </conditions>
      <serverVariables>
        <set name="SKIP_MANAGED_MODULES" value="0" />
      </serverVariables>
      <action type="Rewrite" url="{URL}" />
    </rule>
  </rules>
</rewrite>

Сохраните изменения после завершения работы!

Новое правило совпадает с любым URL-адресом, который до него доходит, и указывает IIS продолжить обработку запроса, сделанного на входящий URL-адрес. Правило также задает переменную сервера с именем "SKIP_MANAGED_MODULES" значением "0", которое равно false. Этот параметр сообщает IIS, что он должен обрабатывать перезаписанный запрос из Url Rewrite так же, как если бы запрос поступил по сети в обычном порядке.

Запуск приложения

В окне командной строки с повышенными привилегиями перезапустите веб-службу World Wide Web Service с помощью команды, показанной ниже:

net stop w3svc & net start w3svc

С помощью нового экземпляра Internet Explorer снова перейдите по следующему адресу:

http://localhost/appinit/default.aspx

Несмотря на то что правила перезаписи URL-адресов теперь используются для определения логики страницы-заставки, вы по-прежнему видите то же поведение из первого пошагового руководства. Изначально отображается страница Startup.htm с серым фоном. Если браузер периодически обновляется, примерно через восемь секунд вы снова увидите переключатель фона страницы на белый, указывающий на то, что "реальная" default.aspx страница обслуживается сейчас, когда инициализация приложения завершена.

Сложные правила страницы-заставки

Предыдущие пошаговое руководство использует инициализацию приложения в качестве прямого сопоставления URL-адреса "X" с URL-адресом "Y". В этом пошаговом руководстве вы будете реализовывать более сложный сценарий инициализации приложений.

В браузере перейдите к обоим из следующих URL-адресов:

• http://localhost/appinit/ImageHandler.ashx?image=Lighthouse
• http://localhost/appinit/ImageHandler.ashx?image=Tulips

Эти URL-адреса являются примерами динамически созданного статического содержимого. Для этого примера приложения код в ImageHandler.ashx обращает внимание на ключ параметра запроса "image". Если значение этой строки запроса имеет значение Lighthouse или Tulips, обработчик ASP.NET передает соответствующий JPG, расположенный в папке App_Data.

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

Изменения на уровне приложения web.config

Используя экземпляр Блокнота с открытым web.config на уровне приложения, добавьте еще одно правило переадресации URL перед последним универсальным правилом. Ниже показан новый фрагмент кода для добавления. Кроме того, вы можете раскомментировать заранее заданное правило обработчика изображений в web.config, расположенное в разделе "Упражнение 3 - Шаг 1 - Правила сложной страницы заставок" в файле web.config.

<rule name="Image Handler Remapping" stopProcessing="true">
  <match url="ImageHandler.ashx" />
  <conditions>
    <add input="{APP_WARMING_UP}" pattern="1" /> 
    <add input="{QUERY_STRING}" pattern="image=([A-Za-z]+)&amp;?" /> 
  </conditions>
  <action type="Rewrite" url="Images/{C:1}_static.jpg" appendQueryString="false" />
</rule>

Сохраните изменения после завершения.

Как и в случае с правилами перезаписи для default.aspx и "/", этот правило имеет атрибут stopProcessing с значением true, чтобы убедиться, что запросы к ImageHandler.ashx не случайно попадают в окончательное правило перезаписи catch-all во время инициализации приложения.

Для запросов к ImageHandler.ashx правило перезаписи использует группу записи регулярных выражений для извлечения запрошенного изображения из строки запроса. Шаблон определения шаблона соответствия ="image=([A-Za-z]+)&?" сообщает IIS извлечь значение переменной строки запроса image. Затем это значение используется в атрибуте URL-адреса атрибута действия: url="Images/{C:1}_static.jpg".

Атрибут URL-адреса в элементе действия сообщает модулю Перезаписи URL-адресов, чтобы переписать запросы ImageHandler.ashx, чтобы вместо этого указывать на файлы в подкаталоге Images приложения. Кроме того, значение строки запроса, записанное регулярным выражением, используется для формирования имени файла, который в конечном итоге будет обслуживаться из подкаталога Images. Например, запрос на ImageHandler.ashx?image=Tulips будет перезаписан на Images/Tulips_static.jpg.

Если перейти к каталогу inetpub\wwwroot\appinit с помощью проводника Windows и посмотреть в подкаталоге "Изображения", вы увидите два файла: один из них представляет "статическую" версию Tulips.jpg, а другая — "статическую" версию Lighthouse.jpg. Эти статические изображения действуют как предварительно созданное содержимое, которое можно обслуживать во время инициализации приложения.

Запуск приложения

В окне командной строки с повышенными привилегиями перезапустите веб-службу World Wide Web Service с помощью команды, показанной ниже:

net stop w3svc & net start w3svc

С помощью Internet Explorer перейдите по адресу:

http://localhost/appinit/ImageHandler.ashx?image=Lighthouse

или

http://localhost/appinit/ImageHandler.ashx?image=Tulips

Обратите внимание, как изображения, возвращаемые в любом случае, включают водяной знак, указывающий, что это статические предварительно сгенерированные версии изображений. Подложка — это текст в верхней части изображения с надписью "Это статическая версия...."

При обновлении браузера примерно через 10 секунд вы увидите, что возвращенное содержимое изображения изменится на "реальное" содержимое, обслуживаемое обработчиком ImageHandler.ashx. Подложка исчезает, что означает, что содержимое теперь динамически создается обработчиком ASP.NET, так как приложение завершило инициализацию.

[Примечание. Если Internet Explorer не обновляется, щелкните значок "сломанный документ" в адресной строке или значок обновления, чтобы принудительно перезагрузить страницу Internet Explorer.]

Сводка

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

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

Для инициализации глобального и локального приложения модуль перезаписи URL-адресов можно интегрировать для предоставления более сложных и более сложных правил инициализации. Используя правила Url Rewrite, интегрированные с функцией Application Initialization, можно подавать различные типы предварительно созданного статического контента для разных URL-адресов и виртуальных путей, в то время как IIS продолжает запускать приложение в фоновом режиме.

Приложение. Настройка примера приложения ASP.NET

Примечание. В следующих шагах предполагается, что на сервере уже установлена версия IIS 8.0, а ASP.NET 4.5 включена для использования в IIS 8.0.

Распаковка примера приложения

Пример приложения ASP.NET содержится в следующем файле .zip:

Распакуйте файл в папку wwwroot на веб-сервере. Например, если веб-сервер установил веб-сайт по умолчанию на диске C:\, распакуйте содержимое файла c:\inetpub\wwwroot\appinit.

Создание приложения в IIS 8.0

После распаковки примера appinit в файловой системе необходимо настроить папку в качестве приложения ASP.NET в IIS 8.0. На снимке экрана ниже показан пример приложения appinit, настроенный как приложение в IIS 8.0. Обратите внимание, что приложение назначается пулу приложений .NET версии 4.5.

Установка модуля перезаписи URL-адресов

Пример приложения использует модуль перезаписи URL-адресов для расширенной интеграции с функцией инициализации приложений. Необходимо установить модуль перезаписи URL-адресов на сервере; Его можно скачать из: https://www.iis.net/downloads/microsoft/url-rewrite

Настройка модуля перезаписи URL-адресов

После установки модуля перезаписи URL-адресов на веб-сервере необходимо изменить файл IIS applicationHost.config, чтобы разрешить использование переменной сервера SKIP_MANAGED_MODULES, поддерживаемой функцией инициализации приложений.

Откройте файл applicationHost.config для всей системы в текстовом редакторе, таком как Блокнот. Например, если вы установили операционную систему на диске C:\, файл applicationHost.config находится по адресу C:\Windows\System32\inetsrv\config.

Прокрутите файл вниз и найдите раздел безопасности. Этот раздел начинается с xml-элемента: <security>.

Введите следующие xml-элементы перед элементом <безопасности> :

<rewrite>
  <allowedServerVariables>
    <add name="SKIP_MANAGED_MODULES" />
  </allowedServerVariables>
</rewrite>

Сохраните изменения в файле applicationHost.config.