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

Возможно, кто-то может пролить свет на этот простой вопрос:

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

Я изучал настройки в пулах приложений и начал задаваться вопросом, почему я даже перерабатывал так часто (один раз каждые 1 000 000 звонков или 2 часа).

Что помешало бы мне устанавливать автоматическую переработку в один раз каждые 24 часа или даже дольше? Почему бы не полностью удалить эту опцию и просто переработать, если память выйдет из-под контроля для appdomain?

Ответ 1

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

Для нас у нас полностью отключена утилизация, и вместо этого есть задача, которая каждую минуту загружает тестовую страницу и запускает iisreset, если она не загружается пять раз подряд.

Ответ 2

Вероятно, вы должны смотреть на переработку с точки зрения надежности. Основываясь на исторических данных, вы должны иметь представление о том, сколько памяти, процессора и т.д. Использует ваше приложение, а также исторические шаблоны и когда возникает проблема. Зная это, вы можете настроить рециркуляцию для устранения этих проблем. Например, если вы знаете, что ваше приложение имеет увеличенный шаблон использования памяти *, что приводит к тому, что приложение заканчивается из памяти через несколько дней, вы можете настроить его на повторное использование до того, как это произошло.

* Очевидно, что вы также захотите разрешить эту ошибку, если это возможно, но утилизация может быть использована для повышения надежности для клиента.

Ответ 3

Причина, по которой они делают это, заключается в том, что приложение может "не работать", даже если процессор и память в порядке (подумайте о взаимоблокировке). Утилизация приложений - это окончательная отказоустойчивая мера, которая может защитить поврежденный код от смерти.

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