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 utilizando 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 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.
Aquí hay otro proveedor de sesiones Memcached en github - https://github.com/rohita/MemcachedSessionProvider –