Ok, así que he estado trabajando en un proyecto ASP.NET por un tiempo y parece que he tomado algunas malas decisiones de diseño que vuelven a atormentarme como el proyecto sigue creciendo cada vez más en términos de datos contenidos.resultados de búsqueda en caché en sesión vs mantener gran montón de objetos limpios
Después de leer sobre la administración de memoria .NET, creo que he identificado un conjunto completo de posibles razones. Dado que las cosas que estoy haciendo no son particularmente especiales, me pregunto si hay un patrón estándar para lograr lo que quiero hacer que me estoy perdiendo.
Tengo una consulta (algo cara) que arroja algo entre 1 y 20000 resultados. En solicitudes posteriores, podemos estar buscando el conjunto de resultados, así que guardo este resultado en la sesión. La sesión es InProc. Me pregunto:
¿Tiene sentido a) almacenar el resultado b) en una sesión c) en proceso? Quiero la velocidad de (a). No sé si hay una forma más eficiente que almacenarla por el usuario (b) y si uso un servidor de estado más sofisticado, ¿no es más lento (c)? ¿O podría ser esa la solución, deshacerse de esos objetos grandes más rápidamente en lugar de mantener el último resultado en la RAM hasta que expire la sesión?
Si cualquier conjunto de resultados> ~ 20000 filas termina arruinando el LOH, ¿existe una forma genérica de evitarlo?
Sé que esta pregunta está poco especificada. Me acabo de dar cuenta de que mi diseño general puede ser defectuoso (escalabilidad w.r.t.), y estoy tratando de estimar exactamente qué tan defectuoso. Espero que se puedan recopilar algunos consejos sobre patrones estándar que, sin embargo, lo conviertan en una pregunta generalmente útil.
Gracias. Las respuestas han sido muy útiles hasta ahora, pero esto realmente encaja muy bien con el tema en cuestión. Comenzamos con un back-end de Access. Ahora estamos a punto de hacer la transición a SQL Server, sin embargo, pensé que si la parte .NET de la aplicación no puede manejar la carga de memoria, no tiene sentido una costosa migración de db si el rendimiento no se incrementa notoriamente. Sin embargo, este podría ser un buen punto que muestra cómo podemos optimizar mejor la parte de .NET con un DB decente detrás (suponiendo que después de una breve investigación de Google que esto no es posible con el acceso para ordenamientos arbitrarios) – Nicolas78
bien encontró una manera de Haga la paginación en access http://stackoverflow.com/questions/1900635/how-do-i-implement-pagination-in-sql-for-ms-access, pero dada la fealdad de la solución en comparación con una formulación sql adecuada allí podría ser todavía un punto para una migración largamente esperada – Nicolas78
Una cosa que puede hacer con el acceso es intentar paginar con un SQL como este: SELECCIONAR ARRIBA (10) DESDE Table1 ORDER BY Id ... Luego almacenar la última ID en un variable y siguiente puede hacer esto: SELECCIONAR ARRIBA (10) DESDE Table1 Donde Id> * LastIdStored * .... ¡Pero la mejor manera es migrar en otro DB! – 2GDev