Was ist in einem ISAPI -Filter ein guter Ansatz für eine gemeinsame Protokolldatei für mehrere Prozesse?

StackOverflow https://stackoverflow.com/questions/1511290

Frage

Ich habe einen ISAPI -Filter, der auf IIS6 oder 7 ausgeführt wird. Wenn mehrere Arbeiterprozesse ("Webgarten") vorhanden sind, wird der Filter geladen und in jedem w3wp.exe ausgeführt.

Wie kann ich dem Filter effizient erlauben, seine Aktivitäten in einer einzigen konsolidierten Protokolldatei zu protokollieren?

  • Protokollnachrichten aus den verschiedenen (gleichzeitigen) Prozessen dürfen sich nicht stören. Mit anderen Worten, eine einzelne Protokollnachricht, die aus einem der w3wp.exe emittiert wurde, muss in der Protokolldatei als einzelne zusammenhängende Zeile realisiert werden.

  • Es sollte nur minimale Auseinandersetzungen für die Protokolldatei geben. Die Websites können 100 Anfragen pro Sekunde dienen.

  • Die strenge Zeitbestellung wird bevorzugt. Mit anderen Worten, wenn w3wp.exe prozess #1 eine Nachricht bei T1 emittiert, verarbeiten #2 eine Nachricht bei T2 und verarbeiten #1 eine Nachricht bei T3, die Nachrichten sollten in der richtigen Zeitreihenfolge in der Protokolldatei angezeigt werden.

Der aktuelle Ansatz, den ich habe, ist, dass jeder Prozess eine separate Protokolldatei besitzt. Dies hat offensichtliche Nachteile.

Einige Ideen:

  • Nominieren Sie einen der W3WP.exe als "Logfile -Eigentümer" und senden Sie alle Protokollnachrichten über diesen speziellen Prozess. Dies hat Probleme im Falle eines Recyclings des Arbeitnehmerprozesses.

  • Verwenden Sie ein OS -Mutex, um den Zugriff auf die Protokolldatei zu schützen. Ist das hohe Zeit genug? In diesem Fall hat jedes w3wp.exe eine Datei in derselben Dateisystemdatei. Muss ich die Protokolldatei nach jedem Schreiben flocken? Ob das funktioniert?

irgendwelche Vorschläge?

War es hilfreich?

Lösung

Zuerst wollte ich sagen, dass ich Ihren aktuellen Ansatz am besten mag, weil jeder Prozess nichts teilt, und dann wurde mir klar, dass sie wahrscheinlich alle die gleiche Festplatte darunter teilen. Es gibt also immer noch einen Engpass, bei dem Streitigkeiten auftreten. Oder sind die OS- und Festplattencontroller vielleicht wirklich schlau, wenn es darum geht, damit umzugehen?

Ich denke, Sie möchten das Schreiben des Protokolls haben, die die Themen, die die wirkliche Arbeit leisten, nicht verlangsamen.

Führen Sie also einen weiteren Prozess auf derselben Maschine aus (niedrigere Priorität?), Die die Protokollnachrichten tatsächlich auf die Festplatte schreiben. Kommunizieren Sie mit dem anderen Prozess mit nicht UDP wie vorgeschlagen, sondern dem Speicher, den die Prozesse teilen. Auch verwirrend als maßgeschneiderte Datei bekannt. Mehr über Speicher zugeordnete Dateien. In meinem Unternehmen haben wir festgestellt, dass Speicherzuordnungsdateien viel schneller als Loopback -TCP/IP für die Kommunikation in derselben Box sind. Ich gehe davon aus, dass es auch schneller als UDP wäre.

Was Sie tatsächlich in Ihrem gemeinsamen Speicher haben, könnte für den Anfang einer std :: walte wenn die push und pops mit einem mutex geschützt werden. Deine Isapi -Threads würden den Mutex greifen, um Dinge in die Warteschlange zu stecken. Der Protokollierungsprozess würde den Mutex greifen, um die Warteschlange auszuziehen, den Mutex freizulassen und dann die Einträge auf die Festplatte zu schreiben. Der Mutex ist nur die Aktualisierung des gemeinsam genutzten Speichers und nicht die Aktualisierung der Datei geschützt. In der Theorie scheint der Mutex für eine bräuliche Zeit gehalten zu werden, wodurch weniger Engpässe geschaffen wird.

Der Protokollierungsprozess könnte sogar die Reihenfolge des Schreibens neu arrangieren, um die Zeitstempel in Ordnung zu bringen.

Hier ist eine weitere Variation: Ziehen Sie für jeden Prozess ein separates Protokoll, aber in jedem Prozess einen Logger-Thread, so dass der zeitkritische Haupterfaden nicht darauf warten muss, dass die Protokollierung auftritt, um mit seiner Arbeit fortzufahren.

Das Problem mit allem, was ich hier geschrieben habe, ist, dass das gesamte System - Hardware, Betriebssystem, die Art und Weise, wie Multicore CPU L1/L2 -Cache funktioniert, Ihre Software - zu komplex ist, um durch einen gerechten IT -Thru -Denken leicht vorhersehbar zu sein. Codieren Sie einige einfache Proof-of-Concept-Apps, instrumentieren Sie sie mit einigen Zeiten und probieren Sie sie auf der realen Hardware aus.

Andere Tipps

Würde sich hier die Anmeldung in einer Datenbank sinnvoll machen?

Ich habe in der Vergangenheit ein UDP-basierter Protokollierungssystem verwendet und war mit dieser Art von Lösung zufrieden.

Die Protokolle werden über UDP an einen Protokoll-Collector-Prozess gesendet, den er für regelmäßig in einer Datei gespeichert hat.

Ich weiß nicht, ob es in Ihrem hohen Kontext funktionieren kann, aber ich war mit dieser Lösung in einer weniger unter Stressanwendung zufrieden.

Ich hoffe, es hilft.

Anstelle eines OS -MUTEX, um den Zugriff auf die Datei zu steuern, können Sie nur Win32 -Dateiverriegelungsmechanismen mit LockFile () und UnlockFile () verwenden.

Mein Vorschlag ist, Nachrichten asynchron (UDP) an einen Prozess zu senden, der die Aufzeichnung des Protokolls übernimmt.
Der Prozess wird:
- Ein Threadempfänger stellt die Nachrichten in eine Warteschlange;
- Ein Thread ist dafür verantwortlich, die Nachrichten aus der Warteschlange zu entfernen, die eine zeitgeordnete Liste einfügt.
- Ein Thread -Monitor -Nachrichten in der Liste und nur Nachrichten mit einer Zeitlänge, die größer als das Minimum ist, sollte in der Datei gespeichert werden (um zu verhindern, dass eine verzögerte Nachricht außerordentlich geschrieben wird).

Sie können sich weiterhin für die trennen Dateien anmelden und ein Tool finden/schreiben, um sie später zusammenzuführen (möglicherweise automatisiert, oder Sie können es einfach an dem Punkt ausführen, an dem Sie die Dateien verwenden möchten.)

Ereignisverfolgung für Windows, enthalten in Windows Vista und später eine gute Fähigkeit dafür.

Auszug:

Die Ereignisverfolgung für Windows (ETW) ist eine effiziente Einrichtung auf Kernelebene, mit der Sie Kernel oder anwendungsdefinierte Ereignisse in einer Protokolldatei protokollieren können. Sie können die Ereignisse in Echtzeit oder aus einer Protokolldatei konsumieren und eine Anwendung debuggen oder feststellen, wo Leistungsprobleme in der Anwendung auftreten.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top