Respostas:
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.