Каково различие между DefaultAppPool и Классиком.NET AppPool в IIS7?
Вам нужно только connectiondate >= CURRENT_DATE:
SELECT COUNT(id) FROM user_connections
WHERE connectiondate >= CURRENT_DATE
, если тип данных connectiondate равен datetime.
Если это date, тогда подойдет простой connectiondate = CURRENT_DATE.
4 ответа
Классический пул обрабатывает запросы в пуле приложений, используя отдельные конвейеры обработки для 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 согласно
Помните, что увеличение этого значения приводит к тому, что приложение потребляет больше ресурсов, например памяти
DefaultAppPool игнорирует настройки для тайм-аута сеанса в web.config, но пул приложений ASPNet будет использовать настройки из web.config.
Думаю, в вашем вопросе есть ответ. IIS 6 и 7 имеют концепцию тайм-аута пула приложений, которая отличается от тайм-аута сеанса.
В чем разница между режимами ... уже рассмотрено. Я не уверен, как ваши вопросы относительно конвейеров и различий в режимах связаны с вашей проблемой - тайм-аутом.
Некоторые перспективы: тайм-аут простоя не возникает на веб-сайте с любым трафиком. У вас, вероятно, есть проблема, которая возникает только на сайте QA или в вашем окне разработчика. Параметр тайм-аута простоя существует для экономии ресурсов на вашем компьютере разработчика и хостинговых компаниях за 5 долларов в месяц с большим количеством недостаточно используемых веб-сайтов (например, в моем блоге). Вероятно, вам не нужен тайм-аут простоя на общедоступном сайте.
Тайм-аут сеанса - устанавливается в веб-конфигурации, если пользователь не попадает на сервер, его сеанс истекает.
Тайм-аут простоя Никто не касается веб-сервера в течение 20 минут, поэтому завершите работу для экономии ресурсов. В IIS 6 это находится на вкладке производительности пула приложений - и его легко отключить. В IIS 7 вы можете задать дополнительные настройки пула приложений или элемент processModel . Я не использую столько же IIS 7, как IIS 6, но похоже, что удаление элемента из web.config или установка значения 0 приводит к бесконечному таймауту простоя.
но похоже, что удаление элемента из web.config или установка значения 0 приводит к бесконечному таймауту простоя. но похоже, что удаление элемента из web.config или установка значения 0 приводит к бесконечному таймауту простоя.В 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, процесс нарушает работу вашего приложения.