Sesión de ASP.NET: objeto grande frente a muchos objetos pequeños

Question

Tengo un escenario para optimizar la forma en que mi aplicación web almacena datos en la sesión y los recupero. Debo señalar que estoy usando SQL Server como mi tienda de sesiones.

Mi caso es que necesito almacenar una lista de identificadores únicos asignados a valores de cadena en la sesión del usuario para su uso posterior. El código actual que heredé usa un List<T> con un objeto personalizado, pero ya puedo ver que algún tipo de diccionario es mucho mejor para el rendimiento.

He probado dos ideas alternativas:

1. Almacenamiento de un Dictionary<int, string> en la sesión. Cuando necesito recuperar las cuerdas, obtengo el diccionario de la sesión una vez y puedo probar cada ID en el objeto del diccionario.

2. Como la sesión es básicamente como un diccionario en sí, almacene la cadena directamente en la sesión utilizando una clave de sesión única, p. Session["MyString_<id>"] = stringValue". Obtener el valor de la sesión sería básicamente la operación inversa.

mis resultados muestran la siguiente función de la operación que necesito hacer y usar 100 cuerdas:

• Diccionario - 4552 bytes, 0,1071 segundos para hacer la operación
• Sesión directo - 4441 bytes , 0.0845 segundos para hacer la operación

De estos resultados veo que guardo algo de espacio en la sesión (probablemente porque no tengo la sobrecarga de serializar un diccionario obj ect) y parece ser más rápido al recuperar los valores de la sesión, tal vez porque las cadenas son más rápidas de deserializar que los objetos.

Así que mi pregunta es, ¿es mejor para el rendimiento almacenar muchos objetos más pequeños en la sesión en lugar de uno grande? ¿Hay alguna desventaja para almacenar muchos objetos más pequeños frente a un objeto más grande que no he visto?

Answer 1

Existen penalizaciones por la serialización y búsqueda de objetos grandes (ocupan más espacio y tiempo de procesador debido a la necesidad de representar una estructura más compleja).

¿Y por qué hacer 2 búsquedas cuando puede hacer solo una?

Además, toda la documentación que trata sobre almacenamiento en caché/soluciones de almacenamiento menciona que es mucho más eficiente serializar un solo valor de una lista basada en una clave calculada, en lugar de almacenar todo el diccionario y recuperarlo y buscar en él.

Answer 2

Creo que casi ha respondido a su propia pregunta al mostrar que sí, que hay una sobrecarga con objetos deserializantes, pero creo que la verdadera razón debería ser una de capacidad de administración y mantenimiento.

El tamaño de la diferencia de almacenamiento va a ser mínimo cuando se habla de 100 objetos, pero a medida que escala hasta 1000 objetos, las diferencias aumentarán también, especialmente si está utilizando objetos personalizados complejos. Si tienes una aplicación que tiene muchos usuarios que usan miles de sesiones, entonces puedes imaginar cómo esto simplemente no es escalable.

Además, al tener muchos objetos de sesión, sin duda tendrá que escribir más código para manejar cada objeto variable.Esto puede no ser una gran cantidad más, pero ciertamente más. Esto también podría dificultar que un desarrollador que esté recogiendo su código comprenda su razonamiento, etc. y por lo tanto amplíe su código.

Si puede manejar la sesión en un solo formato barebones como un IEnumerable o IDictionary, esto en mi opinión es preferible, incluso si hay una ligera sobrecarga implicada.