¿Puedo tener una sección de APP_CODE que se compila por separado del resto de la carpeta?

Question

Tenemos un sitio web con una gran cantidad de objetos almacenados en caché almacenados en variables estáticas dentro de APP_CODE. Cada vez que empujamos un cambio de APP_Code a nuestros servidores web de producción, recicla el grupo IIS y elimina el caché. Sin embargo, no descarga el caché cuando presionamos los cambios en los archivos .aspx y .aspx.cs.

Necesito tener un montón de clases que se actualizarán varias veces al día para poder ser referenciado en APP_CODE. Me gustaría una sección de mi APP_CODE que pueda actualizar varias veces al día sin andar en bicicleta IIS y enjuagar mi caché, o la capacidad de hacer referencia a clases fuera de APP_CODE desde APP_CODE.

¿Hay alguna solución que se ajuste a mi problema?

Answer 1

Actualizaciones a App_code o / bin / siempre recicla sus grupos de aplicaciones, creo. Si está diciendo que tiene un escenario de implementación donde las actualizaciones de archivos .aspx.cs no recicla su grupo de aplicaciones, y si puede consultar el tipo de página en sí, tal vez pueda mover su código a .aspx. Los archivos CS, por lo tanto, eviten que ocurra el reciclaje. Sin embargo, esa puede ser una elección fea.

Una sugerencia es revisar su diseño para reducir la cantidad de actualizaciones de código fuente que se requieren a diario. Tal vez use XML o almacenamiento de bases de datos, y diseñe su aplicación para que sea un poco más genérica y menos propensa a las actualizaciones binarias.

O tal vez divide su aplicación en varias aplicaciones virtuales más pequeñas. El nivel de esfuerzo podría ser más alto para hacer esto, pero en este caso si su aplicación está más compartimentada, no tendrá que reciclar toda la aplicación con cada implementación. Solo tendría que reciclar los módulos que se vieron afectados con su despliegue.

Otra sugerencia podría ser configurar la arquitectura del servidor agrupada. Programe las implementaciones para aplicar a un nodo de clúster, manteniendo solo el otro activo mientras se produce la actualización programada, y luego implementa actualizaciones en el segundo nodo una vez que se realiza la primera actualización del nodo, se recicla el grupo de aplicaciones.

Otra sugerencia sería cambiar sus tiempos de despliegue a tiempos menos extravagantes, si eso es factible.

¿Están ocurriendo las actualizaciones frecuentes solo porque hay muchos cambios de desarrollo?

Answer 2

Otro ángulo sería usar una solución de caché distribuida en lugar de caché HTTPruntime.

HTTPruntime Cache tiene dos inconvenientes principales:

1) Está enjuagado cuando el dominio de su aplicación recicla. Esto se hace de manera predeterminada cada 29 horas de todos modos, incluso si no modifica APP_CODE.

2) Se localiza en un solo servidor web. Entonces, si su servidor web necesita escalar a una granja web más grande, su caché se vuelve cada vez menos efectivo, porque las entradas de caché no están sincronizadas en todos los servidores web.

Las soluciones de caché distribuidas degir estos problemas creando una capa de caché separada entre su nivel web y su fuente de datos de back -end.

Soluciones de ejemplo:

• memcached
• rehacer
• Oracle Coherence (comercial)

Por supuesto, esto dará como resultado una arquitectura más compleja y requerirá más hardware o máquinas virtuales.