Después de una larga lucha con el ciclo de vida de la página en ASP.NET y su rendimiento, hemos comenzado a refactorizar nuestra aplicación web para implementar servicios web (servicios web .asmx .NET simples) y jQuery en el lado del cliente. @ NOTA: esto no implementa MVC o ASP.NET de ninguna manera, estos son solo servicios web.

En ambas dispensaciones de la aplicación, generamos todo el contenido dinámicamente en una sola página. En la dispensación de ASP.NET, esto significaba (debido al ciclo de vida de la página) que toda la página necesitaba ser destruida y reconstruida con (casi) cada llamada AJAX o cambio al formulario web. Esto presentó un gran problema de escalabilidad para una aplicación destinada a servir a muchos usuarios concurrentes. En la dispensación de servicios web / jQuery, podemos enfocarnos selectivamente solo en aquellos elementos del DOM que necesitan enviar o recibir datos al servidor, lo que significa muchas menos solicitudes y una experiencia de usuario mucho más rápida.

La primera iteración de la aplicación mostró una mejora en el rendimiento en un orden de magnitud; sin embargo, a medida que comenzamos a construir más y más servicios web, el rendimiento de la aplicación ahora está a la par con el rendimiento de la dispensación ASP.NET.

Después de muchas búsquedas en Google / soul y pruebas de carga, quedó claro que HTTP Session era el culpable. Esencialmente, cada lectura (y a veces simplemente incluyendo la sesión en el alcance del método del servicio web) es una llamada de bloqueo que introduce un retraso de 500 ms. Una vez que sepa dónde buscar, esto está bien documentado en la literatura de MSDN. Según se implementa, la sesión (si es utilizada por múltiples servicios web por el mismo usuario) transforma las solicitudes asíncronas en solicitudes sincrónicas con un búfer de 500 ms. Actualmente, mitigamos esto encadenando todas nuestras llamadas AJAX como eventos "exitosos" entre sí, haciéndolas solicitudes sincrónicas del lado del cliente. Esto elimina el retraso de 500 ms incurrido al solicitar una lectura en un objeto de sesión bloqueado.

Hacer que la aplicación del lado del cliente se comporte de forma "sincrónica" ha resuelto muchos de los problemas de rendimiento; sin embargo, es solo una solución provisional a corto plazo.

¿Qué alternativas viables (escalables!) Existen para la sesión, de nuevo teniendo en cuenta que no estamos en ASP.NET o MVC o WCF, etc. Nuestro mayor obstáculo es la persistencia de nuestra colección de Metadatos que se inicializa para cada usuario al iniciar sesión. Esta es la operación más cara en la aplicación (por un factor de 10 o más), y una que solo queremos ejecutar una vez. La sesión proporcionó una manera simple de sudar a los viejos una vez y nunca mirar hacia atrás; pero este enfoque parece menos factible.

Un enfoque podría ser eliminar esta única clase de dios de colección de Metadatos y convertir esta clase monoteísta en una colección politeísta de semidioses. Instanciar a los semidioses podría hacerse con mayor frecuencia a un costo menor. Factible pero requiere una considerable refactorización, amplio desarrollo y tiempo de control de calidad. Otro candidato simplemente está almacenando toda la información del estado en la base de datos, pero esto tiene sus propios costos: la latencia no es la menor de ella

¿Hay alguna otra solución a este problema que pueda implicar un menor nivel de esfuerzo para implementar?