Implementación de un TraceListener personalizado en .NET

Question

Estoy buscando las mejores prácticas para implementar un TraceListener que escribirá registros dentro del servidor SQL desde una aplicación ASP.NET.

¿Cuáles son las cosas que se deben tener en cuenta al implementar una clase de este tipo para evitar la reducción de rendimiento?

¿Los procedimientos almacenados serán más rápidos que las declaraciones simples de ADO.NET INSERT?

Me gusta mucho la idea de escribir los registros en un búfer en memoria temporal y enjuagarlo en la base de datos en algún momento posterior de un hilo de fondo, pero ¿qué estructura de datos es la más adecuada para dicho escenario? Queue<T> parece ser un buen candidato pero no puedo agregarle elementos sin algún mecanismo de sincronización.

Encontré en Internet un article que muestra un ejemplo de un TraceListener personalizado que escribe en el servidor SQL pero antes de ponerlo en el código de producción me gustaría recibir más comentarios.

Answer 1

Los procedimientos almacenados no serán más rápidos que el SQL paramteizado. Prefiero un procedimiento almacenado sobre el código duro de SQL en mi aplicación, pero si iba a generar las instrucciones de inserción, eso es aún mejor.

Usar una memoria intermedia es una buena idea si está de acuerdo con la idea de que puede perder datos. Si desea desacoplar el cliente de la inserción y desea que sea duradero, puede usar MSMQ. Luego, podría escribir un servicio de Windows que procesaría la cola y estaría completamente desacoplado de la aplicación. También podría agregar registros de varios servidores si tiene una granja de servidores.

Answer 2

log4net volcará traza a una base de datos SQL con todo un montón de opciones ras etc. comprobarlo: http://logging.apache.org/log4net/release/features.html

log4net está probado. Si puedes evitar "volver a escribir la rueda", está bien ¿no?

Answer 3

no puedo hablar de si los SP son más rápidos que los inserts de ADO, pero siempre sugeriré que se mantengan querys/nonquerys en su aplicación, NO en el almacén de datos. como ahora, el almacén de datos es para datos, no para lógica. evitar SPs.

MS SQL Server es una pieza compleja de la maquinaria y no creo que su aplicación pueda causar el bloqueo en su código de demasiado registro en su base de datos. Obviamente, esto está sujeto a su implementación particular y, por su interés en el rendimiento, podría suponer que tiene la intención de admitir un gran volumen. Lo que estoy diciendo es que no creo que necesite una cola o servicio en la memoria para ajustar el proceso de registro. simplemente descargue el rastro a la base de datos en su aplicación aspnet y olvídese del almacenamiento en caché/descarga. SQL se ocupará de mantener las consultas de registro en la memoria y se ocupará de escribirlas en el disco; de hecho, lo maneja muy bien. El búfer de consulta de SQL se asegurará de que su código no se bloquee cuando elimina su rastro. si no me cree, pruébelo con marcas de tiempo en su ventana de depuración o algo así. si necesita ajustarlo, el ajuste debe estar en la configuración de memoria de su DB. No necesitas inventar un contenedor aquí, usar SP o comenzar otro servicio en tu servidor (como MSMQ), esto consumirá más de tu preciosa CPU y mem.