В чем разница между DefaultAppPool и Classic .NET AppPool в IIS7?
У меня проблема с таймаутами в IIS. В web.config тайм-аут сеанса был установлен на 60 минут, но через 20 минут сеанс заканчивается.
Эта проблема возникает только в IIS7, а не в IIS5.
После некоторого расследования я обнаружил, что это произошло из-за тайм-аута пула приложений. Если пул приложений остается 20 минут бездействия, IIS завершает сеанс.
Если приложение использует defaultAppPool, это всегда происходит, но если я изменю пул приложений на классический пул приложений.NET, тайм-аут не наступает.
Оба режима имеют время простоя, но это происходит только в DefaultAppPool.
- Почему это?
- В чем разница между классическим.NET App Pool и DefaultAppPool?
- Какая разница в конвейере, между Classic и Integrated?
4 ответа
В 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, процесс нарушает работу вашего приложения.
Классический пул обрабатывает запросы в пуле приложений, используя отдельные конвейеры обработки для 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 согласно
помните, что увеличение этого значения приводит к тому, что приложение потребляет больше ресурсов, например памяти
Я думаю, что ваш вопрос имеет ответ. В IIS 6 и 7 есть концепция времени ожидания пула приложений, которое отличается от времени ожидания сеанса.
В чем разница между режимами... уже решено. Я не уверен, как ваши вопросы, касающиеся конвейеров и различий в режимах, связаны с вашей проблемой - временем ожидания.
Некоторая перспектива: Тайм-аут простоя не произойдет на веб-сайте с каким-либо трафиком. Вероятно, у вас есть проблема, которая возникает только на сайте QA или в вашем устройстве разработчика. Параметр тайм-аут простоя существует для экономии ресурсов на вашем устройстве разработчика и хостинговых компаниях по 5 долларов в месяц с большим количеством недостаточно используемых веб-сайтов (например, мой блог). Вы, вероятно, не хотите простоя на общедоступном сайте.
Тайм-аут сеанса - устанавливается в веб-конфигурации, если пользователь не подключается к серверу, время его сеанса истекает.
Тайм-аут простоя Никто не касается веб-сервера в течение 20 минут, поэтому выключите его, чтобы сэкономить ресурсы. В IIS 6 это находится на вкладке производительности пула приложений - и ее легко отключить. В IIS 7 вы можете установить дополнительные параметры пула приложений или элемент processModel. Я не запускаю столько IIS 7, сколько IIS 6, но похоже, что удаление элемента из web.config или установка в 0 приводит к бесконечному времени простоя.
DefaultAppPool игнорирует настройки времени ожидания сеанса в web.config, но ASPNet App Pool будет использовать настройки в web.config.