¿Por qué IIS predetermina el Reciclaje del grupo de aplicaciones cada 1740 minutos?

¿Por qué IIS predetermina el reciclaje del grupo de aplicaciones después de un tiempo determinado? ¿Hay alguna razón específica que no sea que la mayoría de las aplicaciones web no administran la memoria con prudencia? Dado que está administrando la memoria de su aplicación correctamente, ¿es seguro continuar y desactivar esto? ¿Cuáles son algunos posibles inconvenientes, beneficios adicionales de desactivar el reciclaje o mantenerlo?

Sí, la razón por la que se establece una vez al día es por la preocupación de que la aplicación web podría tener una pérdida de memoria. El mayor inconveniente de reciclar frecuentemente los grupos de aplicaciones IIS es que provocará la lectura de web.config, la carga de ensamblados y una recopilación de páginas asp.net y (si no cree en precompilarlas) código subyacente. Este es un proceso bastante pesado y no ocurre hasta la próxima solicitud de una página después de que el grupo de aplicaciones se ha reciclado, lo que ralentiza en gran medida esa solicitud en particular. IIS7 ahora tiene un módulo que puede descargar llamado Application Warm Up para ayudar a "lidiar" con este problema.

Personalmente prefiero usar máximos basados ​​en memoria junto con iniciar sesión en el inicio de la aplicación en lugar de programar mi reciclaje. Esto me permite asumir que mi aplicación no tiene pérdida de memoria y que se demuestre que está equivocada cuando el grupo de aplicaciones se recicla.

1740 minutos son 29 horas:

Cuando IIS 6 se estaba desarrollando, que es la versión que introdujo los grupos de aplicaciones, era necesario establecer un valor predeterminado para el Intervalo de tiempo regular cuando los grupos de aplicaciones se reciclan automáticamente.

Wade sugirió 29 horas por la sencilla 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. En palabras de Wade: "no obtienes un patrón de resonancia". ¡El valor predeterminado ha sido 1740 minutos (29 horas) desde entonces!

http://weblogs.asp.net/owscott/archive/2013/04/06/why-is-the-iis-default-app-pool-recycle-set-to-1740-minutes.aspx

La característica es un remanente de los días clásicos de ASP cuando todo perdía memoria y tenía que hacerlo. La mayoría de la gente tenía un reinicio programado en el servidor web durante la noche. IIS6 automatizó esto con el cierre del grupo de aplicaciones cada 1740 minutos (o si la aplicación está inactiva durante 20 minutos). IIS7 continuó la tradición.

El consejo que recibí de Microsoft en aquellos días era que esto era innecesario a menos que tuvieras una aplicación heredada con una pérdida de memoria conocida. Entonces, si estuviera ejecutando código puramente administrado, estaría bien.

Ciérrelo y monitoree los grupos de aplicaciones. La mayoría de las aplicaciones empresariales complejas utilizan gran cantidad de código heredado y gran parte de ese código tiene algunas fugas. Entonces, para la mayoría de las instalaciones, reiniciar el grupo de aplicaciones ocasionalmente no es una mala idea.

Hay otras opciones como monitorear el tiempo de inactividad que pueden ser una mejor solución para su situación.

La aceleración de un grupo de aplicaciones puede llevar algo de tiempo y hacer que la aplicación sea menos receptiva, por lo que mantenerla activa puede ayudar al rendimiento.

De hecho, esto es puramente para limpiar los recursos filtrados que (podrían) estar presentes. Los 1740 minutos tampoco son el único evento desencadenante. También ocurre después de un número máximo específico de solicitudes o después de exceder una cantidad específica de memoria de proceso de trabajo. Está bastante bien documentado en la biblioteca de MSDN. Desafortunadamente, esta política rompe cosas como el estado de la sesión y las estadísticas como los singletons. Su aplicación deberá ser lo suficientemente robusta como para volver a autenticar a los usuarios y / o reinicializar singletons según sea necesario para evitar perturbar la experiencia de su usuario. Nos obligó a administrar sesiones autenticadas en la base de datos en lugar de en la sesión ASP.NET. De lo contrario, nuestros usuarios fueron reiniciados a nuestra página de inicio de sesión cada vez que el servidor se recicló debido a uno de estos desencadenantes.