Implementación de un TraceListener personalizado en.NET
sql-server logging (3)
Estoy buscando las mejores prácticas para implementar un TraceListener que escriba registros dentro del servidor SQL desde una aplicación ASP.NET.
¿Cuáles son las cosas que deben tenerse en cuenta al implementar dicha clase para evitar la reducción del rendimiento?
¿Los procedimientos almacenados serán más rápidos que las simples declaraciones ADO.NET INSERT?
Realmente me gusta la idea de escribir los registros en un búfer temporal en memoria y enviarlos a la base de datos en algún momento posterior desde un hilo de fondo, pero ¿qué estructura de datos es 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 artículo 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.
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ás de acuerdo con la idea de que podrías 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.
log4net vaciará trace a un sql db con un montón de opciones de descarga, etc. verifíquelo : http://logging.apache.org/log4net/release/features.html
log4net está probado. Si puedes evitar "volver a escribir la rueda", está bien ¿no?
No puedo hablar 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 a 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.