Almacenamiento de datos en memoria: sesión frente a caché frente a estático

Question

Un poco de historia: estoy trabajando en una aplicación web que requiere bastante tiempo para preparar/procesar datos antes de dárselos al usuario para que los edite/manipule. La tarea de solicitud de datos ~ 15/20 segundos para completar y un par de segundos para procesar. Una vez allí, el usuario puede manipular vaules sobre la marcha. Cualquier manipulación de valores requerirá que los datos sean reprocesados ​​por completo.

Actualización: Para evitar confusiones, solo realizo la llamada de datos 1 vez (el hit de 15 segundos) y luego quiero mantener los resultados en la memoria para que no tenga que volver a llamar hasta que el usuario sea 100% hecho trabajando con eso Por lo tanto, la primera extracción llevará un tiempo, pero, usando Ajax, voy a golpear los datos en la memoria para actualizar constantemente y mantener el tiempo de respuesta en alrededor de 2 segundos más o menos (espero).

Para hacer esto eficiente, estoy moviendo los datos iniciales en la memoria y usando las llamadas Ajax al servidor para poder reducir el tiempo de procesamiento para manejar el recálculo que ocurre con las actualizaciones de este usuario.

Aquí está mi pregunta, con el rendimiento en mente, ¿cuál sería la mejor manera de almacenar estos datos, suponiendo que solo 1 usuario estará trabajando con estos datos en un momento dado.

Además, el usuario podría estar trabajando en este proceso durante unas horas. Cuando el usuario esté trabajando con los datos, necesitaré algún tipo de protección contra fallas para guardar los datos actuales del usuario (ya sea en un DB o en un archivo binario serializado) si su sesión se interrumpe de alguna manera. En otras palabras, necesitaré una solución que tenga un enlace apropiado que me permita volcar los datos del objeto de memoria en caso de que el usuario se desconecte/distraiga por mucho tiempo.

Hasta ahora, aquí están mis reflexiones:

estado de sesión - Pros: Cerrado a un usuario. Tiene el evento de fin de sesión que cumplirá mis requisitos de seguridad. Contras: Perforación más lenta de mis opciones actuales. El evento Session End es a veces complicado para garantizar que se active correctamente.

Almacenamiento en caché - Pros: Good Perf. Tiene acceso a dependencias que podrían ser una ventaja más adelante pero no son realmente útiles en el alcance actual. Contras: No es un paso fácil a prueba de fallas que no sea una escritura basada en intervalos de tiempo. Alcance global: deberá garantizar que los usuarios no choquen entre ellos.

Estático - Pros: Mejor Perf. Es fácil de mantener ya que puedo aprovechar directamente mis estructuras de clase actuales. Contras: No es un paso fácil a prueba de fallas que no sea una escritura basada en intervalos de tiempo. Alcance global: deberá garantizar que los usuarios no choquen entre ellos.

¿Alguien tiene alguna sugerencia/comentario sobre qué opción debo elegir?

Gracias!

Actualización: Olvidé mencionar que estoy usando VB.Net, Asp.Net y Sql Server 2005 para realizar esta tarea.

Answer 1

Me gustaría ir con el método de almacenamiento en caché para almacenar los datos en cualquier carga de página. Puede nombrar el caché en el que desea almacenar los datos para evitar conflictos.

Para rastrear los cambios realizados por el usuario, utilizaría un enfoque más antiguo: agregar a un archivo de texto cada vez que el usuario realice un cambio y luego barrer ese archivo a intervalos para guardar los cambios en DB. Si nombra los archivos basados ​​en el usuario/cuenta o algún otro indicador único de sesión, entonces no hay problema con el conflicto y la aplicación (o alguna otra aplicación de soporte, que podría ser una mejor idea en general) puede recorrer todos esos archivos y actualice la base de datos incluso si la sesión ha terminado.

La primera parte de esto puede ajustarse para escalonar la escritura más: guardar los cambios en la Sesión, luego escribirlos en el archivo a intervalos, luego barrer el archivo a intervalos más largos. puede sintonizarlo con el rendimiento y elegir qué nivel de posible pérdida de cambio de usuario será posible.

Answer 2

Use la sesión, pero no confíe en ella.

Simplemente, deje que el usuario "nombre" el conjunto de datos y procure persistir activamente para el usuario, ya sea automáticamente o mediante algo tan simple como el botón "guardar".

No puede confiar en la sesión simplemente porque está (típicamente) vinculada a la instancia del navegador del usuario. Si accidentalmente cierran el navegador (haga clic en el botón X, su PC falla, etc.), entonces perderán todo su trabajo. Lo cual sería desagradable.

Una vez que el usuario tiene ese tipo de control sobre el estado "persistente" de los datos, puede confiar en la sesión para mantenerla en la memoria y aprovecharla como un caché.

Answer 3

Creo que acabas de responder a tu pregunta con los pros/contras. Pero si está buscando la validación de un par, mi voto es para la Sesión. Aunque el rendimiento es más lento (¿sabes por cuánto tiempo más lento?), Tu procesamiento va a tomar mucho tiempo sin importar. ¿Crees que el usuario sabrá la diferencia entre 15 segundos y 17 segundos? Ambos son "para siempre" en términos de la web, por lo tanto, elija uno que parezca más fácil de implementar.

quizás un poco fuera de tema. Recomiendo colocar esas largas llamadas de procesamiento en páginas asincrónicas (que no deben confundirse con asincrónicas de AJAX).

Eche un vistazo a este artículo y devuélvanos un SMS si no tiene sentido.

http://msdn.microsoft.com/en-us/magazine/cc163725.aspx

Answer 4

voy a votar por la opción secreto # 4: Utilice la base de datos para esto. Si está hablando de un tiempo de respuesta de más de 20 segundos en los datos, no obtendrá nada tratando de hacerlo en la memoria, dadas las limitaciones de las opciones que presentó. También podría configurar esto en la base de datos (déle una tabla propia, o incluso una base de datos separada si los requisitos son tan grandes).

Answer 5

Sugiero crear una copia de los datos en una nueva tabla de base de datos (llamémoslo EDITAR) a medida que envía los resultados iniciales al usuario. Si el rendimiento es un problema, hazlo en un hilo de fondo.

A medida que el usuario edita los datos, actualice la tabla (también en una cadena de fondo si el rendimiento se convierte en un problema). Si tiene que usar subprocesos, debe asegurarse de que el primer subproceso finalice antes de comenzar a actualizar las filas.

Esto permite que un usuario se vaya, vuelva, incluso reinicie el navegador y se comprometa siempre que ella se sienta satisfecha con el resultado.

Answer 6

Una posible alternativa a lo que los otros mencionaron es almacenar los datos en el cliente. Suponiendo que el conjunto de datos no es demasiado grande, y el código que lo manipula puede manejarse desde el lado del cliente. Puede almacenar los datos como una isla de datos XML o un objeto JSON. Esta información podría luego ser manipulada/procesada y manejada por el lado del cliente sin viajes redondos al servidor. Si necesita persistir esta información de vuelta al servidor, los datos resultantes finales podrían publicarse a través de una devolución de datos AJAX o estándar.

Si esto no funciona con sus requisitos, me limitaré a almacenarlo en el servidor SQL como sugirió el otro comentario.