Grupo de aplicaciones de IIS/Reiniciar y ASP.NET

Question

Estamos utilizando IIS7 para alojar una aplicación asp.net basada en web. En este entorno, los administradores y desarrolladores pueden implementar código en la aplicación de forma regular.

El nuevo código o aplicación va como una DLL a la carpeta bin de ASP.NET. Tras la implementación de la nueva DLL, IIS reinicia el proceso, impactando (ralentizando) a todos los usuarios en línea.

¿Hay alguna manera de configurar IIS para que ejecute el proceso en segundo plano y, una vez listo, cambiar de estado anterior a nuevo sin afectar a los usuarios?

Gracias de antemano por sus comentarios!

Answer 1

IIS ya lo hace, de eso se trata el reciclaje. Está cargando el archivo DLL mientras la versión anterior de la aplicación aún se está ejecutando. solo después de que esto se complete, el reciclaje se completa.

Sin embargo carga de la DLL es sólo una parte de conseguir que las aplicaciones web listas, también puede haber cargas iniciales como de carga/almacenamiento en caché del usuario db etc.
Estas acciones no son parte del proceso de reciclaje, que sucedan después de que todas las DLL se hayan recargado y el reciclaje ya se haya completado.

Hace un tiempo me encontré con este problema con una aplicación que tenía un gran tiempo de inicio debido a la gran actividad de db/almacenamiento en caché durante el inicio. Entonces, me interesó si hay alguna funcionalidad que nos permita ejecutar código antes de que el reciclado se marque como completado, de modo que la aplicación se considere primero reciclada cuando todo esté listo para ejecutarse. Básicamente lo que quería es algún tipo de funcionalidad de puesta en escena.
Estuve en contacto con el equipo de IIS con respecto a este problema, lamentablemente me dijeron que no existe tal funcionalidad, ni está previsto.

para resolver este podría intentar hacer lo siguiente:

• Uso alterna despliega:
  a configurar 2 sitios web con los grupos de aplicaciones independientes. Uno de ellos es el sitio web EN VIVO, el otro es el sitio web ESCENARIO. Si desea implementar cambios, simplemente implemente en el sitio web STAGED. Después de que todo se carga/almacena en caché, cambia la configuración de la URL de las aplicaciones web para redirigir las solicitudes entrantes de EN VIVO a ESCAPADAS. Entonces el LIVE se convierte en el nuevo STAGED y al revés. El siguiente despliegue iría al nuevo STAGED nuevamente, y así sucesivamente.

ACTUALIZACIÓN
Al parecer, han creado un módulo de IIS que proporciona esta funcionalidad a estas alturas:

Inventario de Aplicación de Calentamiento Módulo para IIS 7.5

El equipo IIS ha lanzado la primera versión de prueba beta del Módulo de calentamiento de aplicación para IIS 7.5. Esto hace que el calentamiento de sus aplicaciones sea aún más fácil de lo que se describió anteriormente. En lugar de escribir código personalizado, especifique las URL de recursos para ejecutar antes de que la aplicación web acepte solicitudes de la red.Este calentamiento ocurre durante el inicio del servicio IIS (si configuró el grupo de aplicaciones IIS como AlwaysRunning) y cuando un proceso de trabajo IIS se recicla. Durante el reciclaje, el antiguo proceso de trabajo de IIS continúa a ejecutar solicitudes hasta que el proceso de trabajo recién generado esté completamente calentado, de modo que las aplicaciones no experimenten interrupciones u otros problemas debido a cachés no imprimados. Tenga en cuenta que este módulo funciona con cualquier versión de ASP.NET, comenzando con la versión 2.0.

Para obtener más información, consulte Calentamiento de aplicaciones en el sitio web de IIS.net. Para ver un tutorial que ilustra cómo usar la función de calentamiento, consulte Primeros pasos con el módulo de calentamiento de aplicación IIS 7.5 en el sitio web de IIS.net .

Ver:

http://www.asp.net/whitepapers/aspnet4

Si utiliza ASP.NET 4 función Auto Start:

Todavía se puede optar por auto-reciclar los procesos de trabajo de time to time. Sin embargo, cuando lo haga, la aplicación se reiniciará inmediatamente y se ejecutará su código de calentamiento (a diferencia de lo que ocurre hoy, donde debe esperar para la próxima solicitud de tareas pendientes).

La principal diferencia entre el calentamiento y la función de inicio automático es que el módulo de calentamiento es parte del proceso de reciclaje. En lugar de bloquear la solicitud de solicitudes, mientras ejecuta el código de inicio.
Lo único que obtiene al usar la función de inicio automático es que no tiene que esperar que un usuario acceda a la página, lo que no ayuda a su caso.

Ver el blog de la Gu:

http://weblogs.asp.net/scottgu/archive/2009/09/15/auto-start-asp-net-applications-vs-2010-and-net-4-0-series.aspx

ACTUALIZACIÓN 2:

Por desgracia, el módulo de calentamiento ha sido descontinuado para IIS 7/7.5:

http://forums.iis.net/t/1176740.aspx

Será parte de IIS8 aunque (Ahora se llama módulo de inicialización de la aplicación):

http://weblogs.asp.net/owscott/archive/2012/03/01/what-s-new-in-iis-8.aspx

Actualización 3:

Como se señaló en los comentarios el módulo Warmup resurgió para IIS 7.5 como Módulo de inicialización de aplicaciones para IIS 7.5 después de que IIS 8 fue lanzado:

http://www.iis.net/downloads/microsoft/application-initialization

Answer 2

La primera parte de ntziolis answer es un poquito inexacta. El proceso de trabajo no se recicla o reinicia, simplemente sigue funcionando. Si este fuera el caso, en los entornos de grupos compartidos tendrías sitios noqueados cada vez que se implementara uno nuevo.

Cuando implementa una nueva aplicación ASP.NET, es el "Dominio de la aplicación" del sitio dentro de, el proceso de trabajo se derriba, no el proceso de grupo.

En el reciclaje Además de la piscina es un concepto totalmente independiente de la implementación

En este punto en el tiempo en la vida comercial de ASP.NET, durante un despliegue, un sitio estará en un estado incoherente hasta que todo el sitio está desplegado Todavía no hay una buena historia sobre esto de Microsoft en este momento para un único sitio en implementaciones de servidor único.

Es por eso que ASP.NET tiene la página especial App_Offline.htm. Está ahí para que pueda habilitar esa página, implementarla y luego desactivarla.

La segunda parte de ntziolis answer es casi correcta, pero no necesita dos sitios o dos grupos de aplicaciones. Solo necesita dos carpetas del sistema de archivos que pasen de ser las carpetas físicas del sitio ... si está en un solo servidor y no detrás de un equilibrador de carga o ARR.

Si sus sitios estuvieran en un servidor web detrás de un equilibrador de carga o ARR, entonces tener dos sitios diferentes tendría sentido, podría enrutar solicitudes de un sitio a otro y hacer robos por turnos en cada implementación.

Obviamente, si hay una gran cantidad de contenido generado por el usuario (archivos cargados y similares), entonces asignaría un directorio virtual en su sitio a una ubicación común para estos datos.

En las implementaciones de mayor escala en las que su aplicación se ejecuta (por ejemplo) en un entorno de carga equilibrada, puede realizar implementaciones más sofisticadas.

para preguntas relacionadas, véase:

How Do I deploy an application to IIS while that web application is running

Publishing/uploading new DLL to IIS: website goes down whilst uploading

Is smooth deployment possible with componentized ASP.NET MVC apps?