Почему IIS по умолчанию перерабатывает пул приложений каждые 1740 минут?

Почему IIS по умолчанию перезапускает пул приложений по истечении заданного времени? Есть ли какая-то конкретная причина, кроме того, что, возможно, большинство веб-приложений не предусмотрительно управляют памятью? Учитывая, что вы правильно управляете памятью своего приложения, безопасно ли идти дальше и отключить это? Каковы некоторые потенциальные отрицательные стороны, преимущества от выключения утилизации или сохранения его?

Да, причина, по которой он используется по умолчанию раз в день, заключается в том, что у веб-приложения может быть утечка памяти. Самым большим недостатком частой переработки пулов приложений IIS является то, что это приведет к чтению web.config, загрузке сборок и перекомпиляции страниц asp.net и (если вы не верите в их предварительную компиляцию) остатков кода. Это довольно сложный процесс, и он не происходит до следующего запроса страницы после перезапуска пула приложений, что значительно замедляет этот конкретный запрос. В IIS7 теперь есть модуль, который можно загрузить, который называется «Разогрев приложения», чтобы помочь «справиться» с этой проблемой.

Лично я предпочитаю использовать максимумы на основе памяти в сочетании с регистрацией при запуске приложения, а не планировать свою переработку. Это позволяет мне предполагать, что в моем приложении нет утечки памяти, и ошибаться при перезагрузке пула приложений.

1740 минут - это 29 часов:

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

Уэйд предложил 29 часов по той простой причине, что это наименьшее простое число за 24 . Он хотел, чтобы шаткий и неповторяющийся паттерн появлялся не чаще, чем раз в день. По словам Уэйда: «Вы не получите резонансный образец». С тех пор по умолчанию было 1740 минут (29 часов)!

http://weblogs.asp.net/owscott/archive/2013/04/06/why-is-the-iis-default-app-pool-recycle-set-to-1740-minutes.aspx

Особенность - пережиток классических дней ASP, когда все просочилось в память, и вам пришлось это делать. У большинства людей был запланирован перезапуск на веб-сервере в одночасье. IIS6 автоматизировал это с отключениями пула приложений каждые 1740 минут (или если приложение простаивает в течение 20 минут). IIS7 продолжил традицию.

Совет, который я получил от Microsoft в те дни, заключался в том, что в этом нет необходимости, если только у вас не было устаревшего приложения с известной утечкой памяти. Так что, если вы выполняете чисто управляемый код, все будет в порядке.

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

Есть и другие варианты, такие как мониторинг времени бездействия, которые могут быть лучшим решением для вашей ситуации.

Раскрутка пула приложений может занять некоторое время и сделать приложение менее отзывчивым, поэтому его поддержание может повысить производительность.

На самом деле, это просто для очистки утечек ресурсов, которые (могут) присутствовать. 1740 минут - не единственное событие запуска. Это также происходит после определенного максимального числа запросов или после превышения определенного объема памяти рабочего процесса. Это довольно хорошо задокументировано в библиотеке MSDN. К сожалению, эта политика нарушает такие вещи, как состояние сеанса и статика, например синглтоны. Ваше приложение должно быть достаточно надежным для повторной аутентификации пользователей и / или повторной инициализации синглетонов, чтобы избежать нарушения работы вашего пользователя. Это заставило нас управлять аутентифицированными сеансами в базе данных, а не в сеансе ASP.NET. В противном случае наши пользователи загружались обратно на нашу страницу входа в систему всякий раз, когда сервер перезагружался из-за одного из этих триггеров.