log4net-Leistung: sollte ich den Loglevel überprüfen, bevor ich versuche, mich einzuloggen?

Question

Würden Sie eine bessere Leistung von A) oder B) erwarten, wenn der Log Level in der log4net Config auf Info level gesetzt ist? Wird _log.Debug allein mehr Code ausführen und länger dauern?

A)

if(_log.IsDebugEnabled) 
    _log.Debug("some message"); 

B)

_log.Debug("some message"); 

Answer 1

In diesem Fall würde ich B. verwenden

Wenn jedoch die Protokollnachricht Konstruktion (das Argument log.Debug) kann eine Weile dauern - zum Beispiel signifikante String-Verkettung - dann würde ich für A gehen. Es wird am Ende der gleiche Test zweimal im "Ja, log es" -Fall durchführen, aber es muss nicht das Protokoll erstellen Nachricht im Fall "Nein, nicht protokollieren".

Answer 2

Obwohl die erste Option etwas performanter ist, würde ich mir keine Sorgen machen.

Allerdings, wenn Sie etwas tun, wie folgt aus:

_log.Debug(String.Format("{0} {1} {2}...", param1, param2, param3)); 

dann ein starker Fall ist, bevor _log.IsDebugEnabled zur Überprüfung.

Answer 3

Ich würde Option B wählen, es sei denn, die Protokollnachricht selbst dauert sehr lange. Der Leistungsgewinn für den üblichen Fall ist vernachlässigbar oder existiert nicht einmal. Intern führt log4net die gleiche Prüfung durch, so dass Sie nichts selbst ändern.

Aber wie gesagt, Option A kann eine gute Idee, in einer Situation wie dieser sein:

if (_log.IsDebugEnabled()) 
{ 
    var message = createComplicatedLogMessageThatTakesALotOfTime(); 
    _log.Debug(message); 
} 

Für alle anderen Fälle, es kommt noch hinzu, drei weitere Linien für jede Nachricht, die Sie gerade einzuloggen, die nicht ist Den Aufwand wert.

Answer 4

Die vorherige Analyse ergab, dass die Implementierung von Log4Net IsXXXEnabled nicht die schnellste ist, da es mehrere andere Methoden aufruft. Die NLog-Version liest flüchtig, ist also viel schneller, aber wenn Ihr Engpass in IsXXXEnabled liegt, machen Sie bereits Low-Latency-Kram und könnten am Ende Ihre eigene dedizierte Protokollierung kochen.

Answer 5

Option A ist besser, denn:

Sie wahrscheinlich nicht wissen, was sich hinter dem Debug() -Methode gewickelt wird. Ist es ein lokaler Wrapper, den jemand hinzugefügt hat, um zusätzliche Logik zu verarbeiten, bevor er an den Debug() - Aufruf von log4net übergeben wird? Was macht log4net in dieser Methode? Sie verwenden möglicherweise die Quelle für log4net, um Ihre Assembly zu erstellen, hat ein anderes Teammitglied sie geändert? Ok, also haben Sie den Code persönlich auditiert, und es ist sehr schnell und Sie verwenden die Assembly von Nuget, damit Sie wissen, dass niemand in Ihrem Team es geändert hat. Was ist mit morgen, wenn eine neue Version von log4net fällt? Woher wissen Sie, dass jemand, der an einem log4net-Bug arbeitet, keinen Logging-Code eingeführt hat, der Ihren Server in all Ihren engen Schleifen schmilzt? Ist der nächste Praktikant, der Ihren Code kopiert und Änderungen daran anwendet, so sachkundig, wie Sie sind, und darüber nachzudenken, wie das Erstellen von ausführlichen komplexen Protokollaufrufen teurer als erwartet sein kann? Beachten Sie auch, dass unterschiedliche Appender möglicherweise unterschiedliche Protokollkosten haben. Was passiert, wenn jemand einen leichten schnellen Async-Appender für einen langsameren synchronen Appender austauscht?

Endergebnis: Code defensiv. Dies ist ein Boolcheck, der wirklich einfach und billig ist und einige unerwartete und knifflige Leistungsprobleme im Maßstab und unter Last verhindern könnte.Werden Sie jemals diesen Scheck sehen und sagen: "Ich bereue es wirklich, das zu schreiben"? Unwahrscheinlich.