Permitir sesión en una granja de servidores web ¿Es StateServer suficientemente bueno?

Question

Antes que nada, para darle un poco de información sobre el entorno actual. Tenemos varias aplicaciones ASP.NET, todas las cuales usan sesión para ciertos aspectos. Estamos "equilibrados de carga" en varios servidores debido a los niveles de tráfico, sin embargo, nuestro balanceo de carga está configurado para usar "Sesiones adhesivas" ya que actualmente todas las aplicaciones web están configuradas para usar "InProc" para el estado de la sesión.

Estamos tratando de poder eliminar la configuración de "Sesiones adhesivas" en nuestro equilibrador de carga, ya que debido a nuestro tráfico, los servidores pueden sobrecargarse y se sobrecargan. Queremos ir con un enfoque más equilibrado, pero debemos poder usar la sesión.

Sé que SqlServer para el estado de la sesión funcionará, pero por razones ajenas a nuestro control, no podemos usar SqlServer para almacenar nuestro estado. Al investigar, parece que StateServer es nuestra mejor opción. Tenemos un servidor adicional, con mucha memoria. Este servidor podría ser nuestro StateServer para todo el Web Cluster. Solo queremos saber las siguientes cosas.

1.) Además de cualquier posible problema de serialización con el cambio de InProc a StateServer, ¿hay problemas importantes conocidos con la pérdida de objetos de sesión o la generación de errores con el entorno mencionado anteriormente?

2.) Aparte del punto único de falla, y un rendimiento un poco más lento, hay otros problemas que debemos tener en cuenta con el uso de StateServer.

3.) ¿Hay alguna métrica que muestre las diferencias de rendimiento entre los tres tipos de almacenamiento de estado?

Answer 1

Aquí es un FAQ decente en estado asp.net: http://www.eggheadcafe.com/articles/20021016.asp

A partir de ese artículo, he aquí algo de información sobre StateServer:

• En una granja de servidores web, asegúrese de que tiene el mismo MachineKey en todos sus servidores web Ver KB 313091 sobre cómo hacerlo.
• Además, asegúrese de que sus objetos sean serializables. Vea KB 312112 para más detalles.
• Para mantener el estado de la sesión en diferentes servidores web de la comunidad web, la ruta de la aplicación del sitio web (por ejemplo \ LM \ W3SVC \ 2) en la metabase de IIS debe ser idéntica en todos los servidores web de la granja de servidores web. . Ver KB 325056 para detalles

Answer 2

Estamos utilizando StateServer para una granja web muy pequeña con solo dos nodos para unos pocos cientos de usuarios.

No soy responsable de su funcionamiento, pero recuerdo solo dos problemas en dos años en los que el servicio tuvo que reiniciarse porque se bloqueó.

Answer 3

Solo he usado sql y in-proc. Pero estos 3 que se aplican cuando se usa el servidor sql también se aplican:

• Evite almacenar demasiada información en la sesión, ya que afecta tanto a la serialización como a los datos transmitidos a través de la red.
• Asegúrese de que no tiene nada que dependa de Session_on End. Esto simplemente no está disponible para sesiones fuera de proceso.
• Desactive la sesión en páginas que no la utilicen. Esto no hace una diferencia para la sesión en proceso, pero para fuera de proceso le ahorrará mucho.

Answer 4

Asegúrate de que las identificaciones etag de tu servidor estén sincronizadas en toda la comunidad web, de lo contrario, se alterará el almacenamiento en memoria caché de los navegadores del cliente.

¿Ha revisado su código en detalle para asegurarse de que todo se pueda serializar fuera de proceso y a través de una LAN de manera eficiente?

¿Está resolviendo el problema principal de rendimiento dentro de su sistema? Lo pregunto porque la base de datos es la fuente típica de controversia.

Mi principal motivación para alejarme de las sesiones adhesivas era la flexibilidad operativa, es decir, bajar el ciclo de un servidor problemático o implementar una actualización de software. Por lo tanto, habiendo implementado un servicio de estado de sesión central, asegúrese de aprovechar al máximo desde un punto de vista operacional.

Answer 5

En mi experiencia, hemos descubierto que el servidor de estado nativo o incluso el uso de SQL Server para sesiones es un escenario muy aterrador ya que ambos tienen problemas (principalmente el rendimiento). Por cierto, también estamos usando sesiones adhesivas.

Creo que puede explorar otros productos para lograr lo mejor. Una opción gratuita sería Velocity pero aún no se ha liberado. Y otro producto integral pero probado será (muy caro en realidad) NCache. Esto incluso ayudará en sus serilizaciones con un menor costo. Si usa su API, obtendrá incluso mejores resultados.

Mire y vea cuál se ve mejor para usted.

Acerca de SQL Server, su servidor morirá muy pronto si tiene suficiente número de visitas entrantes (creo que ya tiene algunos éxitos que le permitieron hacer Web Farm o lo hace solo por el bien de la redundancia)

En pocas palabras: Estamos evaluando Velocity porque NCAchce es realmente costoso. Sin embargo, las ventajas son enormes.

Answer 6

me gustaría otra un punto más a la respuesta aceptada:

• Asegúrese de que la versión de DLL marco es el mismo.

En mi caso, las versiones de System.Web dll eran diferentes, ya que algunas de las actualizaciones de Windows se saltaban en uno de los servidores de la granja.