Почему рабочий процесс IIS перезапускается каждые 29 часов, а не каждые 24 часа?

При настройке сайта в IIS рабочий процесс по умолчанию перезапускается каждые 1740 минут (29 часов). Почему нечетное число, например, 29 часов, а не, например, 24 или 48 часов?

На Tech Ed 2003 докладчику был задан этот вопрос, и ответ состоял в том, что он хотел, чтобы нерегулярный цикл не происходил на ежедневной границе (например, чтобы отличить его от других ежедневных задач, запланированных на сервере / домене).

На сайте здесь (ссылка мертвая) рассуждают:

... (29 - это) первое простое число после 24, что позволяет ему иметь наименьший шанс на то, чтобы происходить в обычном порядке с любым другим серверным процессом; облегчение расследования проблем

Другой сайт, кажется, подтверждает это:

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

ОК, это меня беспокоило, поэтому я покопался и, наконец, нашел это сообщение от парня, который, очевидно, был в команде IIS:

Причина, по которой IIS6 перезапускается каждые 29 часов по умолчанию (и у нас была причина

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

Таким образом, IIS6 построен на предположении (предположительно циничном), что веб-приложение пользователя не будет работать более 24 часов подряд, функции планируются соответствующим образом и выбираются значения по умолчанию. Рабочие процессы перезагружаются каждые 29 часов, отслеживаются запуск и завершение процесса, процесс постоянно проверяется, чтобы убедиться, что он запущен, дескриптор процесса отслеживается и сигнализируется, когда он неожиданно завершается, и т. Д. И т. Д.

Понимая, что переработка является нормальной частью операций, IIS6 также обеспечивает изоляцию такой пересылки от конечного пользователя - TCP-соединение конечного пользователя никогда не прерывается во время перезапуска из-за некоторой магии режима ядра. В сочетании с приложением пользовательского режима, которое хранит состояние сеанса вне процесса (например, ASP.Net Session State Service), практически гарантируется надежное время безотказной работы без потери данных, видимой для пользователя, даже если веб-приложение аварийно завершает работу после каждой обработки запрос пользователя.

Это настолько хорошо, насколько IIS6 может это сделать - учитывая ненадежное веб-приложение, сделать его надежным для конечного пользователя и делать это без необходимости исправления ненадежного веб-приложения.

Конечно, не все ненадежные приложения могут выглядеть надежными - если это так, то у нас все без работы! - но IIS6, конечно, гораздо больше пытается быть устойчивым.

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

Предполагая, что ваше веб-приложение никогда не имеет проблем и остается в состоянии сеанса в процессе, вы можете изменить следующие значения по умолчанию: 1. Отключите 29-часовой периодический повторный пуск 2. Отключите 20-минутный тайм-аут

Это предотвратит неожиданную потерю состояния сеанса.

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