Quelle est la rapidité d'une méthode de journalisation log4net (débogage, informations, etc.)?

Question

Je suis un grand fan de log4net , mais certains (dans mon département) se sont récemment interrogés. son inclusion dans nos projets en raison de la lourdeur apparente de chaque méthode d’exploitation forestière. Je dirais qu’il existe de meilleures techniques que d’autres, mais c’est une autre question.

Je suis curieux de savoir quel est l’impact typique d’un appel de type log4net DebugFormat sur vos applications. Je vais laisser de côté des variables telles que le nombre d'instructions de journal par lignes de code, etc., car je ne fais que rechercher tout ce que vous avez vu dans le monde réel.

Et je suis conscient de la technique simple consistant à ajouter une clause de protection à de longues déclarations d'évaluation, par exemple:

if (log.IsDebug)
{
  log.DebugFormat(...);
}

Excluons donc cela pour le moment.

Answer 1

Je ne connais pas log4net, ni log.DebugFormat (...).

Mais le coût de la journalisation est vraiment dans deux domaines.

Le premier correspond à l'appel de journalisation et le second à la persistance réelle des informations du journal.

Les gardes aident à réduire au minimum l'appel de journalisation lorsque la journalisation n'est pas réellement nécessaire. Cela a tendance à être très rapide, puisqu'il ne s'agit guère que d'un appel de méthode et d'une comparaison de deux scalaires.

Toutefois, lorsque vous n'utilisez pas de gardes, le coût de la création des arguments de journalisation risque de devenir le prix.

Par exemple, dans log4j, il s’agissait d’un idiome courant:

log.debug("Runtime error. Order #" + order.getOrderNo() + " is not posted.");

Ici, le coût correspond à l'évaluation réelle de l'expression de chaîne constituant le message. En effet, quel que soit le niveau de journalisation, cette expression et la chaîne résultante sont créées. Imaginez si vous aviez plutôt quelque chose comme:

log.debug("Something wrong with this list: " + longListOfData);

Cela pourrait créer une variable chaîne volumineuse et coûteuse qui serait gaspillée si le niveau de journalisation n'était pas défini pour DEBUG.

Les gardes:

if (log.isDebug()) {
    log.debug(...);
}

Éliminez ce problème, car l'appel isDebug est bon marché, surtout par rapport à la création de l'argument.

Dans mon code, j'ai écrit un wrapper pour la journalisation et je peux créer des journaux comme celui-ci:

log.debug("Runtime error. Order # {0} is not posted.", order.getOrderNo());

C’est un bon compromis. Cela repose sur des variables Java, et mon code vérifie le niveau de journalisation, puis formate le message de manière appropriée. C'est presque aussi rapide que les gardes, mais c'est beaucoup plus propre à écrire.

Maintenant, log.DebugFormat peut bien faire une chose similaire, que je ne sais pas.

A cela s’ajoute bien sûr le coût réel de la journalisation (à l’écran, dans un fichier, dans un socket, etc.). Mais ce n'est qu'un coût que vous devez accepter. Dans la mesure du possible, ma meilleure pratique consiste à router les messages de journal réels vers une file d'attente, qui est ensuite récoltée et transmise au canal approprié à l'aide d'un thread distinct. Cela permet au moins de garder la journalisation en décalage par rapport à l’informatique principale, mais elle a des coûts et une complexité qui lui sont propres.

Answer 2

Je sais que c'est un ancien fil de discussion, mais pourquoi ne pas utiliser une approche qui évite de remplir le code avec des instructions if basées sur le niveau de journalisation, tel que celui-ci: http://www.beefycode.com/post/Extension- Méthodes pour la mise en forme différée des messages dans Log4Net.aspx

En utilisant l'expression lambda pour construire le message, vous pouvez même éviter de l'évaluer entièrement.

Answer 3

La la FAQ de log4net a une réponse à cette , mais pas au niveau de détail que vous recherchez.

En résumé: utilisez ces clauses de garde.

Answer 4

Il suffit de donner à la réponse de Will Hartung une perspective .NET:)

Le code DebugFormat est:

if (IsDebugEnabled)
{
    Logger.Log(ThisDeclaringType, m_levelDebug, new SystemStringFormat(CultureInfo.InvariantCulture, format, args), null);
}

En gros, c'est la même chose, donc je pense que lorsque vous utilisez DebugFormat, vous n'avez pas besoin d'utiliser la clause guard (vous pouvez toujours avoir une petite surcharge mais je pense que c'est assez petit pour être ignoré)

aurait laissé un commentaire mais je n'ai pas assez de réputation: /