Risposte:
A Tech Ed 2003, al presentatore è stata posta questa domanda e la risposta è stata che desideravano un ciclo irregolare per impedire che si verificasse su un limite giornaliero (ad esempio per distinguere da altre attività quotidiane pianificate sul server / dominio).
Il sito qui (Link morto) ipotizzava:
... (29 è il) primo primo dopo 24, permettendogli di avere la minima possibilità che si verifichi in modo regolare con qualsiasi altro processo server; facilitare l'indagine sui problemi
Un altro sito sembra confermare questo:
( Wade Hilmo ) ha suggerito 29 ore per la semplice ragione che è il numero primo più piccolo su 24. Voleva uno schema sfalsato e non ripetitivo che non si verifica più frequentemente di una volta al giorno
OK, questo mi stava infastidendo, quindi ho scavato e finalmente ho trovato questo post da un ragazzo che apparentemente faceva parte del team IIS:
Il motivo per cui IIS6 ricicla ogni 29 ore per impostazione predefinita (e avevamo un motivo
Il motivo per cui IIS6 ricicla ogni 29 ore per impostazione predefinita (e abbiamo avuto un motivo per scegliere 29 ore come valore predefinito) è perché molto probabilmente, l'applicazione Web in esecuzione su di essa è inaffidabile e deve letteralmente riavviarsi frequentemente.
Pertanto, IIS6 è basato sulla premessa (ammettentemente cinica) che l'applicazione Web dell'utente non funzionerà per più di 24 ore contigue, le funzionalità sono pianificate di conseguenza e le impostazioni predefinite sono state scelte. I processi di lavoro vengono riciclati ogni 29 ore, l'avvio e l'arresto del processo vengono monitorati, il processo viene costantemente sottoposto a ping per assicurarsi che sia in esecuzione, l'handle del processo viene monitorato e segnalato quando termina in modo imprevisto, ecc.
Rendendosi conto che il riciclaggio è una parte normale delle operazioni, IIS6 si assicura anche di isolare tale riciclaggio dall'utente finale: la connessione TCP dell'utente finale non si interrompe mai durante un riciclo, a causa della magia in modalità kernel. In combinazione con l'applicazione in modalità utente che memorizza lo stato della sessione fuori processo (come ASP.Net Session State Service), si ottiene virtualmente un tempo di attività affidabile affidabile senza perdita di dati visibile all'utente, anche se l'applicazione Web si arresta in modo anomalo dopo l'elaborazione di ogni singolo richiesta dell'utente.
Questo è circa quanto IIS6 può farcela: data un'applicazione Web inaffidabile, rendila affidabile per l'utente finale e fallo senza richiedere correzioni dell'applicazione Web inaffidabile.
Naturalmente, non tutte le applicazioni inaffidabili possono apparire affidabili - in tal caso, allora siamo tutti senza lavoro! - ma IIS6 cerca sicuramente molto di più di essere resiliante.
Nel tuo caso, accade che la resiliancy abbia un effetto collaterale sullo stato dell'utente non persistente, ma può essere facilmente regolata.
Supponendo che la tua applicazione web non abbia mai un problema e rimanga nello stato della sessione in corso, vorrai modificare questi valori predefiniti: 1. Disattiva il riciclo periodico di 29 ore 2. Disattiva il timeout di inattività di 20 minuti
Ciò impedirà la perdita imprevista dello stato della sessione.
Naturalmente, se mai usi un'applicazione con stato di sessione out-of-process, puoi lasciare tutto come predefinito e non notare mai una differenza di funzionalità o affidabilità.