asp.net - publicar - ¿Permitir sesión en una granja web? ¿Es StateServer suficientemente bueno?

publicar sitio web en iis windows 10

Question

En primer lugar, 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 considerando la posibilidad de eliminar la configuración de "Sesiones adhesivas" en nuestro equilibrador de carga, ya que debido a las cargas de tráfico, los servidores pueden sobrecargarse. 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 que escapan 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 único punto 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í hay unas preguntas frecuentes decentes sobre el estado asp.net: http://www.eggheadcafe.com/articles/20021016.asp

De ese artículo, aquí hay información sobre StateServer:

• En una granja de servidores web, asegúrese de tener la misma MachineKey en todos sus servidores web. Ver KB 313091 sobre cómo hacerlo.
• Además, asegúrese de que sus objetos sean serializables. Ver KB 312112 para más detalles.
• Para que el estado de la sesión se mantenga en diferentes servidores web en la granja de servidores 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

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

¿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ás resolviendo el principal problema de rendimiento dentro de tu 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 fue la flexibilidad operativa, es decir, 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 3

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 4

Solo he usado sql e in-proc. Pero estos 3 que se aplican al usar el servidor sql se aplican también:

• 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 no tener nada que dependa de Session_on End. Esto simplemente no está disponible para sesiones fuera de proceso.
• Desactivar la sesión en páginas que no la usan. Esto no hace una diferencia para la sesión en proceso, pero para fuera de proceso le ahorrará mucho.

Answer 5

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

Creo que puedes explorar otros productos para lograr lo mejor. Una opción gratuita sería Velocity pero aún no se ha lanzado. 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.

Eche un vistazo 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 otro punto más a la respuesta aceptada:

• Asegúrese de que la versión de Framework dlls sea la misma.

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