2011-01-08 21 views
5

Actualmente tengo un escenario en el que 1000 acciones podrían producirse en cuestión de segundos y que necesito para almacenar todas estas acciones en una base de datos.Cómo iniciar sesión con eficacia 100s a 1000 de acciones a una base de datos

Lo que hago actualmente es mantener un temporizador inactivo, una vez que este temporizador alcanza un tiempo predefinido, tomo las acciones almacenadas en caché (acciones desde la última confirmación, que es solo una lista simple) y las comprometo a la base de datos.

La interfaz de usuario tiene que ser sensible como sea posible (duh?).

Aparte de empujar el registro de base de datos para un hilo independiente, ¿hay otras sugerencias con el rendimiento que alguien me puede ayudar con?

+5

"De 100 a 1000 acciones podrían ocurrir en cuestión de segundos" - ¡no son tantas! –

+0

Estoy a favor del hilo por separado y la idea de cola concurrente segura. Sencillo. Limpiar. (El hilo del escritor puede separarse de la cola si puede, pero de lo contrario, KISS.) –

Respuesta

4

Trate de usar marcos de registro de 3 ª parte como NLog que tienen envoltorio registro asíncrono.

+1

Estoy de acuerdo con esto. log4net funciona bastante bien para mí. –

2

Iniciar las acciones a la cola de un archivo de registro como se producen las acciones. Esto tiene dos beneficios. Es muy rápido y, por lo tanto, su UI sigue siendo receptiva y significa que si la aplicación falla, las acciones no se pierden.

Luego tienen un subproceso de fondo que toma las acciones en el archivo y actualiza la base de datos. Después de que la aplicación falla, puede reiniciar y el hilo de fondo simplemente se actualiza con las acciones que se guardaron de manera segura en el pasado. Incluso podría tener un servicio de aplicación/proceso/Windows separado que realice la actualización en segundo plano y que la aplicación de interfaz de usuario solo realice la escritura de registro.

Si realmente debe evitar un hilo separado, entonces deberá realizar la base de datos udpates en lotes muy pequeños, para que sean lo más rápidos posible y en el tiempo de procesamiento inactivo. Pero este enfoque siempre será inferior porque la operación de la base de datos pasa a ser sincrónica con su UI. Entonces su UI se cuelga por la duración. Cualquier problema en la base de datos, como un tiempo de espera debido a problemas de conectividad, mata a la IU.

Cuestiones relacionadas