Log4net est-il beaucoup plus lent que System.Diagnostics.Trace?

Question

J'étudie les différences entre log4net et System.Diagnostics.Trace pour la journalisation, et je suis curieux de connaître les différences de performances que j'ai observées.

J'ai créé une application de test pour comparer les performances des deux méthodes de journalisation dans plusieurs scénarios et je constate que log4net est nettement plus lent que la classe Trace . Par exemple, dans un scénario où je consigne 1 000 messages sans format de chaîne, le temps d'exécution moyen de log4net sur 1 000 essais est de 9,00 ms. Trace s’exécute avec une moyenne de 1,13 ms. Un grand nombre de mes tests ont une assez grande variance dans les temps d'exécution de log4net. la nature périodique des exécutions longues aberrantes semble suggérer une interférence de la part du GC. Le fait de fouiller avec CLR Profiler confirme qu’il existe une grande quantité de collections pour une tonne d’objets log4net.Core.LoggingEvent qui sont générés (pour être juste, cela ressemble à Trace généré une tonne d’objets Char [] également, mais n’affiche pas la grande variance que fait log4net.)

Une chose que je garde à l’esprit ici est que, même si log4net semble environ 9 fois plus lent que Trace , la différence est de 8 ms sur 1 000 itérations; ce n'est pas exactement une perte de performance significative. Néanmoins, certains de mes cas d'utilisation prévus peuvent appeler des méthodes qui enregistrent des centaines de milliers de fois, et ces chiffres proviennent de ma machine rapide. Sur une machine plus lente, plus typique de la configuration de nos utilisateurs, la différence est de 170 ms à 11 ms, ce qui est un peu plus alarmant.

Ces performances sont-elles typiques de log4net ou existe-t-il des pièges qui peuvent considérablement augmenter les performances de log4net?

( NOTE: je suis conscient que le formatage de chaîne peut modifier le temps d'exécution; j'essaie de comparer des pommes avec des pommes et j'ai des scénarios de test sans formatage et des scénarios de test avec formatage; log4net reste proportionnellement lent si chaîne le formatage est utilisé ou non. )

L'histoire jusqu'à présent:

• Robert Gould a la meilleure réponse à la question; J'étais surtout curieux de savoir s'il était typique de voir log4net fonctionner beaucoup plus lentement que la classe Trace .
• La réponse d’Alex Shnayder est une information intéressante, mais elle n’entre pas vraiment dans le champ de la question. La moitié de l’intention d’introduire cette journalisation est d’aider au débogage des problèmes de logique et de performances sur les systèmes actifs; nos clients placent nos produits dans de nombreux scénarios exotiques qui sont souvent difficiles à reproduire sans configurations matérielles coûteuses et à grande échelle. Ma principale préoccupation est qu’une différence de temps importante entre " non logging " et " journalisation " pourrait affecter le système de telle sorte que les bugs ne se produisent pas. En fin de compte, l’ampleur de la baisse des performances est grande mais l’ampleur est petite, j’espère donc que ce ne sera pas un problème.

Answer 1

oui log4xxx est plus lent que trace, puisque trace est normalement un outil proche du noyau, tandis que log4xxx est un outil beaucoup plus puissant. Personnellement, je préfère log4xxx pour sa fexibilité, mais si vous voulez quelque chose qui n’a pas autant d’impact, et que vous n’avez pas vraiment besoin de journaux pour la production, par exemple, dans le débogage, seul le traçage devrait suffire.

Remarque: j’utilise log4xxx car la même chose s’applique à toutes les langues avec une bibliothèque log4 et pas seulement .Net

Answer 2

La bibliothèque Common.Logging pourrait vous intéresser. C'est un wrapper d'abstraction mince sur les implémentations de journalisation existantes et vous permet de brancher n'importe quelle infrastructure de journalisation que vous aimez au moment de l'exécution. En outre, il est beaucoup plus rapide que System.Diagnostics.Trace, comme décrit dans mon billet de blog sur les performances .

hth, Erich

Answer 3

D'après mon expérience, les performances de log4net ne sont pas un problème dans la plupart des cas. La vraie question est de savoir pourquoi vous auriez même besoin de "consigner des choses des centaines de milliers de fois". dans un système de production.
Selon moi, en production, vous ne devez enregistrer que le strict minimum (info et nd peuvent être un niveau d'avertissement), et ce n'est que si nécessaire (déboguer un problème sur site) que le débogage doit être activé au niveau du débogage.

Answer 4

Si vous voulez le meilleur des deux mondes, log4net vous permettra également de vous connecter au traceur aspnet. J'active cette option lorsque je souhaite obtenir des statistiques de performances liées à des événements spécifiques de ma journalisation.

Answer 5

Vient d'exécuter un test comparant l'écriture séquentielle à un fichier simple par rapport à l'utilisation de Log4Net pour la même tâche. Log4Net est environ 400 fois plus lent que le StreamWriter.So Je considère que Log4Net n'est pas utilisable si vous écrivez trop fichiers journaux . Mais je trouve cela très utile pour de petites quantités d’entrées de journal et le débogage.

Peut-être une solution pour isoler la journalisation dans un thread séparé dans certains cas.