Problemas de equilibrio de carga de ASP.NET AJAX

Question

Esta sería una pregunta para cualquiera que tenga código en la carpeta App_Code y utilice un equilibrador de carga de hardware.Es cierto que el equilibrador de carga de hardware podría configurarse en sesiones fijas para resolver el problema, pero en un mundo perfecto, me gustaría que la función estuviera desactivada.

Cuando un archivo en la carpeta App_Code y el sitio no está precompilado, generará nombres de archivo aleatorios para estos archivos.

server1 "/ajax/SomeControl, App_Code.tjazq3hb.ashx"
server2 "/ajax/SomeControl, App_Code.wzp3akyu.ashx"

Entonces, cuando un usuario publica la página y se transfiere al otro servidor, nada funciona.

¿Alguien tiene una solución para esto?Podría cambiar a un sitio web precompilado, pero nuestro departamento de control de calidad perdería la capacidad de promocionar los archivos modificados.

Answer 1

Puede mover lo que esté en su código de aplicación a una biblioteca de clases externa si su departamento de control de calidad puede promover esa biblioteca completa.Creo que estás atrapado con sesiones fijas si no puedes encontrar una forma conveniente o tolerable de cambiar a un sitio precompilado.

Answer 2

¿Tiene el nodo <machinekey> en ambos servidores configurado con el mismo valor?

Puede anular el archivo machine.config en web.config para configurar esto.Esto debe coincidir, de lo contrario, pueden surgir situaciones extrañas como esta.

Answer 3

¿Su balanceador de carga admite sesiones fijas?Con esto activado, el equilibrador enrutará la misma IP al mismo servidor una y otra vez dentro de un período de tiempo determinado.De esta manera, todas las solicitudes (AJAX o de otro tipo) de un cliente siempre llegarán al mismo servidor en el clúster/granja.

Answer 4

Bueno, lo primero es lo primero...Lo de MachineKey es cierto.Es absolutamente necesario establecer el mismo valor en todas las máquinas con equilibrio de carga.No recuerdo todo lo que afecta, pero hazlo de todos modos.

En segundo lugar, continúe y precompila el sitio.De hecho, aún puede publicar nuevas versiones, siempre que haya un archivo .cs para una página, esa página se vuelve a compilar.Lo que se vuelve complicado son los archivos app_code que se compilan en un solo dll.Sin embargo, si se realiza un cambio allí, puede cargar el nuevo dll y nuevamente todo debería estar bien.

Para facilitar aún más las cosas, habilite la opción "Nombres fijos usados ​​y conjuntos de una sola página".Esto garantizará que las cosas tengan el mismo nombre en cada compilación, por lo que simplemente pruebe y luego reemplace los archivos .dll modificados.

Dicho todo esto, no deberías tener ningún problema tal como está.La solicitud va a IIS, que simplemente muestra la página y la compila según sea necesario.Si el código subyacente es diferente en cada máquina, realmente no debería importar, el código es el mismo y esa máquina hará referencia a su propio código.La solicitud/devolución de datos real no sabe ni le importa nada de eso.Todo lo que dije anteriormente debería ayudar a simplificar las cosas, pero debería funcionar de todos modos...entonces probablemente sea un problema de clave de máquina.

Answer 5

Si se trata de un equilibrador de carga de hardware, no debería tener ningún problema, porque todo lo que se sabe allí es la URL de solicitud, en la que el servidor compilaría la página solicitada y la entregaría.

El único problema que se me ocurre que podrías tener es con la sesión y el estado de vista.

Answer 6

Es cierto que el equilibrador de carga de hardware podría configurarse en sesiones fijas para resolver el problema, pero en un mundo perfecto, me gustaría que la función estuviera desactivada.

Answer 7

Parece que es sólo para el cifrado ViewState.No afecta los nombres de archivos para ensamblados compilados automáticamente.

Answer 8

Creo que el modelo asp.net depende bastante del cifrado y del almacenamiento específico de la máquina, por lo que no estoy seguro de si funciona para evitar una IP fija para la sesión.

No conozco ASP.NET AJAX (en su lugar, uso el enfoque MonoRail NJS), pero el estado de la sesión podría ser un problema para usted.

Debe asegurarse de que los estados de la sesión sean serializables y no utilice la sesión InMemory.Probablemente necesite ejecutar ASP.NET Session State Server para asegurarse de que toda la granja de servidores frontend esté utilizando el mismo almacenamiento de sesión.En tal caso, la sesión debe ser perfectamente serializable (es por eso que no se prefiere ningún objeto en la sesión, siempre debe usar ID, y apuesto a que MS mantiene esta limitación cuando desarrollan la biblioteca AJAX)