asp.net sql-server session session-state stateserver

Parámetros de rendimiento de estado de sesión de ASP.NET



sql-server session (2)

Tengo experiencia personal, pero no hay puntos de referencia o métricas reales registradas para compartir. Inicialmente creamos un sitio Asp.Net que almacenaba un objeto de usuario más grande de lo habitual en sesión utilizando el método InProc. Descubrimos que el tamaño del objeto y la naturaleza de nuestras bibliotecas de manejo de errores causaban 2 comportamientos no deseados. El primero fue un reciclaje del grupo de aplicaciones a intervalos aleatorios durante los procesos. Debido a que el proceso w3wp.exe se reciclaría midstream, esencialmente se descartaría la sesión y el objeto se perdería. Esto provocó que otro código se activara y reparara la sesión, y aumentó la latencia de nuestras transacciones. También descubrimos (aunque no fue un problema terrible y solo descubrí al intentar depurar la pérdida de memoria que acabo de describir) que el tamaño del objeto en sesión junto con algunos de los objetos que se cargan en las bibliotecas de la página causarían w3wp.exe para entrar y salir de la página repetidamente. Para solicitudes más pequeñas que solo involucraban el objeto de sesión o estos objetos de la biblioteca, pero no ambos, no había un comportamiento de búsqueda extraño en el proceso.

Al pasar de InProc a StateServer, descubrimos un retorno inmediato al reciclaje. El grupo realmente terminó reciclando menos, e incluso cuando lo hizo nuestros objetos de sesión permanecieron en memoria separada. También notamos que esto creó una condición universal de "solo biblioteca" como se describió anteriormente con respecto a la búsqueda y no la volvimos a experimentar (aunque reconocí que dejé de verificar después de 1 mes de tiempo de actividad). Recopilamos una latencia muy pequeña para acceder a ciertas bibliotecas de framework en ese momento, pero cuando actualizamos de 2.0 a 3.5, estas anomalías de acceso desaparecían por completo. Esperamos un comportamiento similar cuando actualicemos de 3.5 a 4.0 pronto.

Se intentó un sitio de prueba que utiliza SQLServer como controlador de estado, y la única latencia que encontramos fue la creación / almacenamiento de la sesión inicial. Las llamadas posteriores para actualizar / acceder a la sesión en SQL no proporcionaron ninguna diferencia real con la opción StateServer. No tengo ninguna métrica, pero no había nada en ninguno de los sistemas que indicaran una diferencia en el comportamiento. Las marcas de tiempo tienen diferencias comparables en todos los aspectos. Un beneficio que obtuvimos, aunque fue de un potencial de uso excepcional, fue que pudimos combinar nuestra base de datos de usuarios directamente con el servidor de estado de la sesión y comparar las marcas de tiempo, los estados y otras variables de sesión especializadas directamente. No teníamos ninguna necesidad real de esta función, y la opción StateServer ya estaba en pleno funcionamiento en nuestros servidores de producción, por lo que tuvimos la determinación de dejarla tal como estaba.

Al final, no fue tanto la velocidad como el uso de la memoria lo que nos persuadió a volcar InProc para StateServer. Los beneficios de la velocidad de acceso definitivamente no superaron la necesidad de tener los datos en la memoria en primer lugar.

Encontré mucha información excelente que compara InProc, StateServer y SQLServer para la administración del estado de ASP.NET, pero parece que no puedo encontrar ninguna comparación de referencia de rendimiento. Está claro que InProc es más rápido que StateServer, que a su vez es más rápido que SQLServer, pero no está claro cuánto más rápido. Me doy cuenta de que va a variar mucho según la aplicación y el entorno, pero tener una idea relativa de cómo se comparan sería valioso.

¿Conoces algún punto de referencia que se haya realizado y que puedas compartir? o tiene alguna experiencia personal con esto? ¡Gracias!

Hay buenos puntos de referencia para los DevOps Guys. http://www.slideshare.net/devopsguys/best-performing-aspnet-session-state-providers comparando

  • ASP.Net In-Proc
  • Servidor de estado de sesión ASP.Net
  • Servidor ASP.Net Sql
  • CouchBase
  • MongoDb
  • RavenDb
  • Redis (este, TheCloudlessSky , no esta AngiesList )

AppHarbor también recomienda memcached, pero no tiene un punto de referencia. http://support.appharbor.com/kb/tips-and-tricks/using-memcached-backed-sessionprovider y proporciona un proveedor de sesiones https://github.com/friism/Memcached-Providers