Когда вы настраиваете сайт на 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-минутный тайм-аут простоя.
Это предотвратит неожиданную потерю состояния сеанса.
Конечно, если вы когда-нибудь будете использовать приложение с внепроцессным состоянием сеанса, вы можете оставить все по умолчанию и никогда не заметить разницы в функциональности или надежности.