3

We're using Log4j v1.2.14. We're already using org.apache.log4j.ConsoleAppender and now we've a requirement/need to have daily rotating logs in place. Hence, we're planning to use org.apache.log4j.DailyRollingFileAppender to have daily rotating logs.

My question is, is DailyRollingFileAppender an additional overhead/have performance impact over ConsoleAppender, because it has to additionally check for whether the file has to be rotated/rollover in each print statement?

Any opinions/user experience are also appreciated.

Gnanam
  • 10,613
  • 19
  • 54
  • 72

1 Answers1

2

Your arguments are correct and logic dictates that an overhead/performance impact exists. How much? You should measure it by yourself if you're afraid of the performance hit.

It really depends on how many logging statements you have. Lots of debugging statements are the worst because they can impact performance, unless you are using guards of type logger.isDebugEnabled().

If you can afford it, I'd suggest switching to slf4j with Logback as underlying implementation. Logback's main focus is speed and it seems to go to great lengths to make sure it's faster than other logging systems.

darioo
  • 46,442
  • 10
  • 75
  • 103
  • Thanks for letting me know about the existence of another logging framework *slf4j*. So, has slf4j superseded log4j? – Gnanam Dec 01 '10 at 12:14
  • 1
    @Gnanam: take a look at [my answer](http://stackoverflow.com/questions/4311086/any-reason-for-a-new-project-to-use-log4j-instead-of-logback). Slf4j is only an API, and you can use Logback as an implementation. Bonus points: you can also use log4j as an implementation, if you want to. Logback has superseded log4j and was made by the same person who made log4j. – darioo Dec 01 '10 at 12:17