В чем разница между DefaultAppPool и Classic .NET AppPool в IIS7?

Question

У меня проблема с таймаутами в IIS. В файле web.config время ожидания сеанса было установлено равным 60 минутам, но через 20 минут сеанс заканчивается.

Эта проблема возникает только в IIS7, а не в IIS5.

После некоторого расследования я обнаружил, что это произошло из-за тайм-аута пула приложений. Если пул приложений остается 20 минут бездействующим, IIS завершает сеанс.

Если приложение использует defaultAppPool, это всегда происходит, но если я изменю пул приложений на классический пул приложений .NET, время ожидания не наступит.

Оба режима имеют время простоя, но только в DefaultAppPool это происходит.

• Почему это?
• В чем разница между классическим .NET AppPool и DefaultAppPool?
• Какая разница в конвейере между Classic и Integrated?

Answer 1

В IIS7 внесены некоторые важные изменения для лучшей поддержки WCF, и одним из ключевых элементов является новый интегрированный пул приложений. Этот сеанс от PDC рассказывает о некоторых из этих проблем с точки зрения повышения эффективности работы служб WCF: http://channel9.msdn.com/pdc2008/TL38/

На этой странице представлен хороший обзор архитектуры IIS7: http://learn.iis.net/page.aspx/101/introduction-to-iis7-architecture/. Ниже приведены некоторые ключевые сведения из этой статьи, касающиеся двух различных типов пулов приложений:

Режим интегрированного пула приложений

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

Классический режим пула приложений

Когда пул приложений в классическом В режиме IIS 7.0 запросы обрабатываются как в Режим изоляции рабочих процессов IIS 6.0. ASP.NET запросы сначала проходят родные шаги обработки в IIS и затем направляется в Aspnet_isapi.dll для обработка управляемого кода в управляемое время выполнения. Наконец, запрос направляется обратно через IIS для отправки ответ. Это разделение IIS и ASP.NET модели обработки запросов приводит к дублированию некоторых этапы обработки, такие как аутентификация и авторизация. Кроме того, функции управляемого кода, такие как формы проверки подлинности, только доступны для приложений ASP.NET или приложения для которых у вас есть скрипт сопоставил все запросы, которые будут обработаны aspnet_isapi.dll. Не забудьте проверить свой существующие приложения для совместимость в интегрированном режиме до модернизации производства среда для IIS 7.0 и назначение приложения в пулы приложений в Интегрированный режим. Вы должны только добавить приложение в пул приложений в классическом режиме, если приложение не работает в интегрированном режиме. За Например, ваше приложение может полагаться на токене аутентификации, переданном из IIS для управляемой среды выполнения, и, в связи с к новой архитектуре в IIS 7.0, процесс ломает ваше приложение.

Answer 2

Классический пул обрабатывает запросы в пуле приложений, используя отдельные конвейеры обработки для IIS и ISAPI. Integrated использует интегрированный конвейер, IIS и ASP.NET a (лучшая производительность) использует преимущества улучшенных функций IIS 7.0, используя только один процесс. Хорошей практикой является создание нового пула приложений для каждого приложения, а затем индивидуальная настройка в соответствии с требованиями приложения.

---

Классический режим выполняет следующие действия:

1.Входящий HTTP-запрос принимается через ядро ​​IIS.

2. Запрос обрабатывается через ISAPI.

3. Запрос обрабатывается через ASP.NET.

4. Запрос проходит через ISAPI.

5. Запрос проходит обратно через ядро ​​IIS, где, наконец, доставляется HTTP-ответ

---

Интегрированный режим использует:

1.Входящий HTTP-запрос принимается через ядро ​​IIS и ASP.NET.

2. Соответствующий обработчик выполняет запрос и доставляет ответ HTTP

Увеличьте время ожидания сеанса в web.config согласно

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

Answer 3

Я думаю, что на ваш вопрос есть ответ. В IIS 6 и 7 есть концепция времени ожидания пула приложений, которое отличается от времени ожидания сеанса.

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

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

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

Время ожидания простоя Никто не касается веб-сервера в течение 20 минут, поэтому выключите его, чтобы сэкономить ресурсы. В IIS 6 это находится на вкладке производительности пула приложений - и ее легко отключить. В IIS 7 можно установить дополнительные параметры пула приложений или элемент processModel . Я не запускаю столько IIS 7, сколько IIS 6, но похоже, что удаление элемента из web.config или установка в 0 приводит к бесконечному времени простоя.

Answer 4

DefaultAppPool игнорирует настройки времени ожидания сеанса в web.config, но ASPNet App Pool будет использовать настройки в web.config.