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

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

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

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

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

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

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

Ответы

Ответ 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, например аутентификация. Дополнительно, Интегрированный режим доступность управляемых функций для всех типов контента.

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

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

Ответ 2

Классический пул обрабатывает запросы в пуле приложений, используя отдельные конвейеры обработки для IIS и ISAPI. интегрированный использует интегрированный конвейер, IIS и ASP.NET(более высокая производительность) использует преимущества улучшенных функций 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 согласно

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

Ответ 3

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

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

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

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

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

Ответ 4

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