Implementieren eines benutzerdefinierten TraceListeners in .NET

Question

Ich bin auf der Suche nach bewährten Verfahren zur Implementierung eines TraceListener die von einer ASP.NET-Anwendung aus Protokolle in den SQL-Server schreibt.

Was sollte bei der Implementierung einer solchen Klasse beachtet werden, um Leistungseinbußen zu vermeiden?

Werden gespeicherte Prozeduren schneller sein als einfache ADO.NET INSERT-Anweisungen?

Ich mag die Idee des Schreibens der Protokolle in einen temporären In-Memory-Puffer und Flush es an die Datenbank zu einem späteren Zeitpunkt von einem Hintergrund-Thread, aber welche Datenstruktur ist am besten geeignet für ein solches Szenario? Warteschlange<T> scheint ein guter Kandidat zu sein, aber ich kann ihm keine Elemente ohne einen Synchronisationsmechanismus hinzufügen.

Ich habe über das Internet eine Artikel das ein Beispiel für einen benutzerdefinierten TraceListener zeigt, der in den SQL-Server schreibt, aber bevor ich es in den Produktionscode einfüge, würde ich gerne mehr Feedback erhalten.

Answer 1

log4net speichert Trace in eine Sql-DB mit einer ganzen Reihe von Flush-Optionen usw. Prüfen Sie es: http://logging.apache.org/log4net/release/features.html

log4net hat sich bewährt. Wenn man vermeiden kann, das Rad neu zu schreiben, ist das doch gut, oder?

Answer 2

Stored Procedures werden nicht schneller sein als parametrisiertes SQL. Ich bevorzuge eine Stored Procedure gegenüber der Hardcodierung von SQL in meiner Anwendung, aber wenn Sie die Einfügeanweisungen generieren wollen, ist das sogar noch besser.

Die Verwendung eines Puffers ist eine gute Idee, wenn Sie damit einverstanden sind, dass Sie Daten verlieren könnten. Wenn Sie den Client von der Einfügung entkoppeln wollen und es dauerhaft sein soll, könnten Sie MSMQ verwenden. Dann könnten Sie einen Windows-Dienst schreiben, der die Warteschlange verarbeitet und vollständig von der Anwendung entkoppelt ist. Bei einer Serverfarm könnte er auch Protokolle von mehreren Servern zusammenfassen.

Answer 3

Ich kann nicht sagen, ob SPs schneller sind als ADO Einfügungen, aber ich werde immer vorschlagen, halten Abfragen/Nicht-Abfragen in Ihrer Anwendung, NICHT in den Datenspeicher. wie Sie jetzt, der Datenspeicher ist für Daten, nicht Logik. vermeiden SPs.

MS SQL Server ist ein komplexes Stück Maschinerie und ich glaube nicht, dass Ihre Anwendung in der Lage wäre, Blockierung in Ihrem Code von zu viel Protokollierung zu Ihrer DB zu verursachen. Natürlich ist dies abhängig von Ihrer speziellen Implementierung und von Ihrem Interesse an der Leistung könnte ich davon ausgehen, dass Sie beabsichtigen, ein hohes Volumen zu unterstützen. was ich damit sagen will, ist, dass ich nicht glaube, dass Sie eine In-Memory-Warteschlange oder einen Dienst benötigen, um den Protokollierungsprozess zu verpacken. spülen Sie einfach den Trace an die DB in Ihrer Aspnet-App und vergessen Sie Caching/Flushing. SQL kümmert sich darum, die Logging-Abfragen im Speicher zu halten und sie auf die Festplatte zu schreiben - in der Tat verwaltet es dies sehr gut. Der Abfragepuffer von SQL stellt sicher, dass Ihr Code nicht blockiert, wenn Sie Ihren Trace flushen. Wenn Sie mir nicht glauben, testen Sie es mit Zeitstempeln in Ihrem Debug-Fenster oder etwas anderem. Wenn Sie es optimieren müssen, sollte dies in den Speichereinstellungen Ihrer Datenbank geschehen. Sie müssen hier keinen Wrapper erfinden, SPs verwenden oder einen anderen Dienst auf Ihrem Server starten (wie MSMQ), dies wird nur noch mehr Ihrer kostbaren CPU und Ihres Speichers beanspruchen.