Respuestas:
En Tech Ed 2003, se le hizo esta pregunta al presentador, y la respuesta fue que querían un ciclo irregular para evitar que ocurriera en un límite diario (por ejemplo, para distinguir de otras tareas diarias programadas en el servidor / dominio).
El sitio aquí (Enlace muerto) especuló:
... (29 es el) primer primo después de 24, lo que le permite tener la menor probabilidad de ocurrir en un patrón regular con cualquier otro proceso de servidor; facilitando la investigación de problemas
Otro sitio parece confirmar esto:
( Wade Hilmo ) sugirió 29 horas por la simple razón de que es el número primo más pequeño sobre 24. Quería un patrón escalonado y no repetitivo que no ocurra con más frecuencia que una vez al día
OK, esto me estaba molestando, así que busqué y finalmente encontré esta publicación de un tipo que aparentemente estaba en el equipo de IIS:
La razón por la que IIS6 recicla cada 29 horas de forma predeterminada (y teníamos una razón
La razón por la que IIS6 se recicla cada 29 horas de manera predeterminada (y teníamos una razón para elegir 29 horas como valor predeterminado) es porque lo más probable es que la aplicación web que se ejecuta en él no sea confiable y literalmente necesite reiniciarse con frecuencia.
Por lo tanto, IIS6 se basa en la premisa (es cierto que es cínica) de que la aplicación web del usuario no se ejecutará durante más de 24 horas contiguas, las características se planifican en consecuencia y se eligen los valores predeterminados. Los procesos de los trabajadores se reciclan cada 29 horas, se monitorea el inicio y el apagado del proceso, el proceso se fija constantemente para asegurarse de que se esté ejecutando, el controlador del proceso se rastrea y se señala cuando finaliza inesperadamente, etc.
Al darse cuenta de que el reciclaje es una parte normal de las operaciones, IIS6 también se asegura de aislar dicho reciclaje del usuario final: la conexión TCP del usuario final nunca termina durante un reciclaje, debido a cierta magia en modo kernel. Combinado con la aplicación en modo de usuario que almacena el estado de sesión fuera de proceso (como el Servicio de estado de sesión ASP.Net), se garantiza virtualmente un tiempo de actividad confiable sin pérdida de datos visibles para el usuario, incluso si la aplicación web falla después de procesar cada uno de ellos solicitud del usuario.
Esto es casi tan bueno como IIS6 puede hacerlo: dada una aplicación web poco confiable, hacer que parezca confiable para el usuario final y hacerlo sin requerir ninguna solución de la aplicación web no confiable.
Por supuesto, no todas las aplicaciones poco confiables pueden parecer confiables; si es así, ¡nos quedamos sin trabajo! - pero IIS6 seguramente intenta mucho más ser flexible.
En su caso, simplemente sucede que la resistencia tiene un efecto secundario en el estado del usuario no persistente, pero se puede ajustar fácilmente.
Suponiendo que su aplicación web nunca tenga un problema y permanezca con el estado de sesión en proceso, querrá cambiar estos valores predeterminados: 1. Apague el reciclaje periódico de 29 horas 2. Apague el tiempo de inactividad de 20 minutos
Esto evitará la pérdida inesperada del estado de la sesión.
Por supuesto, si alguna vez usa una aplicación con un estado de sesión fuera de proceso, puede dejar todo como predeterminado y nunca notar una diferencia en la funcionalidad ni la confiabilidad.