No hay absolutamente ninguna duda al respecto. ASP.NET ha madurado y una gran mayoría de las aplicaciones ASP.NET ahora son de alto tráfico y de misión crítica. Eso significa que no puede permitirse el tiempo de inactividad no programado de todo el sitio web o de algunos de los servidores donde muchos usuarios están siendo eliminados. Esto se debe a que estos tiempos de inactividad le cuestan mucho en ingresos perdidos y una mala reputación que es difícil de arreglar.
El almacenamiento de estado de sesión de ASP.NET, si no se maneja correctamente, puede causar tiempos de inactividad no programados. Microsoft ofrece cuatro opciones de almacenamiento para el estado de sesión de ASP.NET:
- En proceso: Sesiones mantenidas dentro del proceso de trabajo
- servidor de estado: Sesión mantenida en un proceso separado
- Servidor SQL: Sesión mantenida en SQL Server
- Personalizado: Sesión guardada en una tienda personalizada de terceros
Ambos En proceso y StateServer no tienen la capacidad de replicar el estado de sesión de ASP.NET en más de un servidor y, por lo tanto, provocan la pérdida de datos si algún servidor web deja de funcionar. De hecho, si tienes un solo EstadoServidor para todo el sitio web y se cae, estás totalmente perdido porque todo tu sitio web se caerá.
Servidor SQL es la tercera opción de almacenamiento para el estado de sesión de ASP.NET y proporciona redundancia de servidor y replicación de datos porque puede crear un clúster de base de datos, ya sea duplicado o con equilibrio de carga.
Sin embargo, es costoso configurar clústeres de SQL Server y existen alternativas más baratas y viables disponibles. Además, SQL Server (como todas las bases de datos relacionales) se diseñó para almacenar datos relacionales estructurados y no BLOB; mientras que el estado de sesión de ASP.NET se almacena en SQL Server como BLOB. Por lo tanto, no solo el acceso a las sesiones es lento, sino que la base de datos se convierte rápidamente en un cuello de botella cuando intenta escalar su aplicación.
Una alternativa considerablemente mejor a todo esto es utilizar la opción de almacenamiento personalizado de Estado de sesión de ASP.NET y use un caché distribuido en memoria (NCache) como su almacenamiento de estado de sesión de ASP.NET. NCache replica las sesiones en varios servidores, por lo que si un servidor deja de funcionar, no se pierden los datos de la sesión. NCache también es mucho más rápido de acceder que SQL Server porque está en la memoria. Por fin, NCache le permite escalar fácilmente el clúster de caché a medida que crece el tamaño de su granja web. Simplemente agregue más servidores de caché al clúster para que nunca haya cuellos de botella.
Y, lo mejor de todo, no se necesita programación para usar NCache para almacenamiento de estado de sesión ASP.NET. Simplemente modifique su web.config para especificar lo siguiente:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
<assemblies> <add assembly="Alachisoft.NCache.SessionStoreProvider, Version=4.4.0.0, Culture=neutral, PublicKeyToken=CFF5926ED6A53769"/> </assemblies> <sessionState cookieless="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="20"> <providers> <add name="NCacheSessionProvider" type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" sessionAppId="NCacheTest" enableLogs="false" cacheName="myReplicatedCache"/> </providers> </sessionState> |
Bueno, si tiene una aplicación ASP.NET ejecutándose en una granja web, eche un vistazo a NCache y vea cómo mejorará su almacenamiento de estado de sesión ASP.NET. Aquí hay algunos enlaces útiles para NCache:
Puede comenzar con un mínimo de dos servidores dedicados en un clúster de caché para una alta disponibilidad y confiabilidad y, luego, se recomienda mantener una proporción de 4:1 entre sus servidores web/de aplicaciones y los servidores de caché para obtener un rendimiento y una escalabilidad óptimos para sus aplicaciones. .