Por que o processo do operador do IIS recicla a cada 29 horas e não a cada 24 horas?

Quando você configura um site no IIS, o processo de trabalho é padronizado para reciclagem a cada 1740 minutos (29 horas). Por que um número ímpar como 29 horas e não, por exemplo, 24 ou 48 horas?

No Tech Ed 2003, o apresentador recebeu essa pergunta e a resposta era que eles queriam um ciclo irregular para impedir que ocorresse em um limite diário (por exemplo, para diferenciar de outras tarefas diárias agendadas no servidor / domínio).

O site aqui (link morto) especulou:

... (29 é o) primeiro prime após 24, permitindo que ele tenha a menor chance de ocorrer em um padrão regular com qualquer outro processo do servidor; facilitando a investigação de problemas

Outro site parece confirmar isso:

( Wade Hilmo ) sugeriu 29 horas pela simples razão de que é o menor número primo entre 24. Ele queria um padrão escalonado e não repetitivo que não ocorra com mais frequência do que uma vez por dia

OK, isso estava me incomodando, então eu procurei e finalmente encontrei essa postagem de um cara que aparentemente estava na equipe do IIS:

O motivo pelo qual o IIS6 recicla a cada 29 horas por padrão (e tivemos um motivo

O motivo pelo qual o IIS6 recicla a cada 29 horas por padrão (e tivemos um motivo para escolher 29 horas como o valor padrão) é porque, mais provavelmente, o aplicativo Web em execução nele não é confiável e literalmente precisa reiniciar com freqüência.

Portanto, o IIS6 é construído com base na premissa (reconhecidamente cínica) de que o aplicativo Web do usuário não será executado por mais de 24 horas contíguas, os recursos serão planejados de acordo e os padrões escolhidos. Os processos do trabalhador são reciclados a cada 29 horas, a inicialização e o desligamento do processo são monitorados, o processo é constantemente ativado para garantir que esteja em execução, o identificador do processo é rastreado e sinalizado quando termina inesperadamente, etc.

Percebendo que a reciclagem é uma parte normal das operações, o IIS6 também se certifica de isolar essa reciclagem do usuário final - a conexão TCP do usuário final nunca termina durante uma reciclagem, devido a alguma mágica no modo kernel. Combinado com o aplicativo no modo usuário que armazena o estado da sessão fora de processo (como o ASP.Net Session State Service), é garantido um tempo de atividade confiável garantido praticamente sem perda de dados visível pelo usuário, mesmo se o aplicativo da web travar após o processamento de todos os Solicitação de usuário.

Isso é tão bom quanto o IIS6 pode torná-lo - dado um aplicativo da web não confiável, faça com que pareça confiável para o usuário final e faça isso sem exigir nenhuma correção do aplicativo da web não confiável.

Obviamente, nem todos os aplicativos não confiáveis ​​podem parecer confiáveis ​​- nesse caso, estamos todos sem empregos! - mas o IIS6 com certeza tenta muito mais ser resiliente.

No seu caso, acontece que a resiliência tem um efeito colateral no estado do usuário não persistente, mas pode ser facilmente ajustada.

Supondo que seu aplicativo Web nunca tenha um problema e permaneça com o estado da sessão em processo, você desejará alterar os seguintes padrões: 1. Desative a reciclagem periódica de 29 horas 2. Desative o tempo limite de inatividade de 20 minutos

Isso impedirá a perda inesperada do estado da sessão.

Obviamente, se você usar um aplicativo com estado de sessão fora de processo, poderá deixar tudo como padrão e nunca perceber uma diferença na funcionalidade nem na confiabilidade.