Comments on: EJAPP Top 10 countdown: #10 – Excessive logging http://blog.xebia.com/2007/02/18/ejapp-top-10-countdown-10-excessive-logging/ Thu, 11 Mar 2010 16:23:01 +0100 http://wordpress.org/?v=2.8.4 hourly 1 By: Le top 10 des problèmes de performances des applications J2EE par J2EE, Agilité et SOA : Le blog de Xebia France http://blog.xebia.com/2007/02/18/ejapp-top-10-countdown-10-excessive-logging/comment-page-1/#comment-7055 Le top 10 des problèmes de performances des applications J2EE par J2EE, Agilité et SOA : Le blog de Xebia France Thu, 03 May 2007 12:38:25 +0000 http://blog.xebia.com/2007/02/18/ejapp-top-10-countdown-10-excessive-logging/#comment-7055 [...] #10 - Logging excessif [...] [...] #10 – Logging excessif [...]

]]> By: Xebia France Blog http://blog.xebia.com/2007/02/18/ejapp-top-10-countdown-10-excessive-logging/comment-page-1/#comment-5158 Xebia France Blog Sun, 04 Mar 2007 23:24:42 +0000 http://blog.xebia.com/2007/02/18/ejapp-top-10-countdown-10-excessive-logging/#comment-5158 [...] Plusieurs problèmes dans cette approche: - le logger utilisé porte le nom de la classe. Il doit être configuré comme tel (y compris avec les mécanisme d'héritage). Les noms de classe (et de package) n'ont pas vraiment de sens pour les équipes d'exploitation, ce qui limite souvent leur autonomie sur la configuration des traces. - les messages de debug manquent de consistance, et n'ont de véritable intérêt que pour le développeur au moment de la mise au point de la classe concernée (ce qui, notons-le, n'est pas critique; par nature, les messages de déboguage ne sont pas destinés aux exploitants). - si plusieurs threads exécutent simultanément la méthode, les traces seront entrelacées et il sera difficile de rétablir le séquencement des opérations - le message d'erreur est laconique et la pile d'appel, pour utile qu'elle soit, n'est interprétable que par l'ingénierie. - il n'y a pas de trace intermédiaire entre DEBUG et ERROR, ce qui limite la capacité de diagnostic en exploitation - l'utilisation des API de log tel quel peut poser des problèmes de performance (cf ce billet) [...] [...] Plusieurs problèmes dans cette approche: – le logger utilisé porte le nom de la classe. Il doit être configuré comme tel (y compris avec les mécanisme d’héritage). Les noms de classe (et de package) n’ont pas vraiment de sens pour les équipes d’exploitation, ce qui limite souvent leur autonomie sur la configuration des traces. – les messages de debug manquent de consistance, et n’ont de véritable intérêt que pour le développeur au moment de la mise au point de la classe concernée (ce qui, notons-le, n’est pas critique; par nature, les messages de déboguage ne sont pas destinés aux exploitants). – si plusieurs threads exécutent simultanément la méthode, les traces seront entrelacées et il sera difficile de rétablir le séquencement des opérations – le message d’erreur est laconique et la pile d’appel, pour utile qu’elle soit, n’est interprétable que par l’ingénierie. – il n’y a pas de trace intermédiaire entre DEBUG et ERROR, ce qui limite la capacité de diagnostic en exploitation – l’utilisation des API de log tel quel peut poser des problèmes de performance (cf ce billet) [...]

]]> By: Ceki Gulcu http://blog.xebia.com/2007/02/18/ejapp-top-10-countdown-10-excessive-logging/comment-page-1/#comment-5138 Ceki Gulcu Sat, 03 Mar 2007 19:56:37 +0000 http://blog.xebia.com/2007/02/18/ejapp-top-10-countdown-10-excessive-logging/#comment-5138 The way SLF4J handles parameterized logging has nothing to do with JDK 1.5. SLF4J targets JDK 1.3 and above. The time it takes to build the formatted message in SLF4J, that is parsing log.debug("Entered myMethod with arguments {}, {}", arg0, arg1); is ten times faster than parsing log.debug("Entered myMethod with arguments ${0}, ${1}", arg0, arg1); We got the numbers from very simple benchmarks we did. The way SLF4J handles parameterized logging has nothing to do with JDK 1.5. SLF4J targets JDK 1.3 and above.

The time it takes to build the formatted message in SLF4J, that is parsing

log.debug(”Entered myMethod with arguments {}, {}”, arg0, arg1);

is ten times faster than parsing
log.debug(”Entered myMethod with arguments ${0}, ${1}”, arg0, arg1);

We got the numbers from very simple benchmarks we did.

]]> By: Vincent Partington http://blog.xebia.com/2007/02/18/ejapp-top-10-countdown-10-excessive-logging/comment-page-1/#comment-5099 Vincent Partington Thu, 01 Mar 2007 12:16:32 +0000 http://blog.xebia.com/2007/02/18/ejapp-top-10-countdown-10-excessive-logging/#comment-5099 Ceki, isn't it interesting that the JDK 1.5 language features provide performance benefits in such an unexpected area! I don't fully understand your point though: is the SLF4J logging idiom two times or ten times faster than the JBoss idiom? Have you get a benchmark for this? Ceki, isn’t it interesting that the JDK 1.5 language features provide performance benefits in such an unexpected area! I don’t fully understand your point though: is the SLF4J logging idiom two times or ten times faster than the JBoss idiom? Have you get a benchmark for this?

]]> By: Ceki Gulcu http://blog.xebia.com/2007/02/18/ejapp-top-10-countdown-10-excessive-logging/comment-page-1/#comment-4921 Ceki Gulcu Mon, 19 Feb 2007 14:28:30 +0000 http://blog.xebia.com/2007/02/18/ejapp-top-10-countdown-10-excessive-logging/#comment-4921 The <a href="http://www.slf4j.org/faq.html#logging_performance" rel="nofollow"> logging idiom</a> proposed by SLF4J executes about ten times faster than the JBoss alternative. In practice, there won't be any difference when a logging request is disabled. However, when the request is enabled, than the SLF4J version will typically log twice as fast. The logging idiom proposed by SLF4J executes about ten times faster than the JBoss alternative. In practice, there won’t be any difference when a logging request is disabled. However, when the request is enabled, than the SLF4J version will typically log twice as fast.

]]>