Log4j performance issues

[Michael A Chase <mc...@ix.netcom.com>]

In the most recent update to our system, I installed log4j 1.2.11.  After
the update someone at our hosting facility finally noticed that the
application was taking a very long time to paint some screens.  The
application was frequently painfully slow to begin with, but someone
latched on to log4j as something that had changed recently.

In production, the application is calling Logger.getLogger() once for most
class instantiations (5-10 per screen) and logger.warn() once per screen.
There is only one appender which uses DailyRollingFileAppender.

Has anyone seen log4j cause a noticeable performance degradation when
writing one log entry per screen displayed?

-- 
Mac :})
Give a hobbit a fish and he eats fish for a day.
Give a hobbit a ring and he eats fish for an age.



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

Re: Log4j performance issues

[Michael A Chase <mc...@ix.netcom.com>]

On Fri, 04 Nov 2005 09:35:31 -0800, Mark Womack wrote:

> Do you have any actual timing or profiling information that would lead
> you to suspect that log4j is causing the problem, or just anecdotal
> experience? There is nothing I can think of that changed so much in any
> of the recent log4j releases to account for the level of degradation you
> are describing and have not seen it myself.
> 
> If you switch back to version 1.2.9, does your problem go away?

Version 1.2.11 was our first version of log4j, prior to that we were
generating much larger logs using (ServletContext).log(). Nobody has any
numbers, it's just that log4j is new here and the people that probably
should be fixing their previously existing performance problems are trying
to blame it.

-- 
Mac :})
Give a hobbit a fish and he eats fish for a day.
Give a hobbit a ring and he eats fish for an age.



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

Re: Log4j performance issues

[Mark Womack <mw...@apache.org>]

Do you have any actual timing or profiling information that would lead you
to suspect that log4j is causing the problem, or just anecdotal experience?
There is nothing I can think of that changed so much in any of the recent
log4j releases to account for the level of degradation you are describing
and have not seen it myself.

If you switch back to version 1.2.9, does your problem go away?

-Mark

On 11/3/05, Michael A Chase <mc...@ix.netcom.com> wrote:
>
> In the most recent update to our system, I installed log4j 1.2.11. After
> the update someone at our hosting facility finally noticed that the
> application was taking a very long time to paint some screens. The
> application was frequently painfully slow to begin with, but someone
> latched on to log4j as something that had changed recently.
>
> In production, the application is calling Logger.getLogger() once for most
> class instantiations (5-10 per screen) and logger.warn() once per screen.
> There is only one appender which uses DailyRollingFileAppender.
>
> Has anyone seen log4j cause a noticeable performance degradation when
> writing one log entry per screen displayed?
>
> --
> Mac :})
> Give a hobbit a fish and he eats fish for a day.
> Give a hobbit a ring and he eats fish for an age.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>

Re: Log4j performance issues

[Michael A Chase <mc...@ix.netcom.com>]

On Fri, 04 Nov 2005 00:55:22 -0500, Frank W. Zammetti wrote:

> One thing that I'm curious about... are you actually instantiating a new 
> Logger on each class instantiation (in the constructor I would guess)? 
> If so, you might want to try making it a static member so the Logger 
> instantiation doesn't happen with each class instantiation.  This is 
> described in the Log4J docs (I believe it's kind of the normal, accepted 
> way), and it's how I've personally always done it.  It may make no 
> difference at all, but I don't know what the overhead of that 
> getLogger() call is, might be interesting to avoid it and see if there 
> is any difference.

I started out assigning logger at object construction time because some of
the classes get inherited and I wanted the logger to reflect the actual
class of the current object.  I also am using MDC to hold a session/thread
marker and set that in the factory that gets called in the logger factory.
I think those issues may not matter for classes that don't get inherited,
so I'll probably make the logger field static final in those classes.

-- 
Mac :})
Give a hobbit a fish and he eats fish for a day.
Give a hobbit a ring and he eats fish for an age.



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

Re: Log4j performance issues

["Frank W. Zammetti" <fz...@omnytex.com>]

I'm using Log4J underneath JCL, and doing considerably more logging than 
one entry per screen, and the performance of the one app I'm thinking of 
in particular is stellar.  And the hardware isn't anything grand and the 
load is pretty significant, so I would say Log4J, in and of itself, 
isn't the problem.

Of course, there could be something peculiar to your setup or 
environment, and maybe it only manifests itself with the newer version, 
but who knows.

One thing that I'm curious about... are you actually instantiating a new 
Logger on each class instantiation (in the constructor I would guess)? 
If so, you might want to try making it a static member so the Logger 
instantiation doesn't happen with each class instantiation.  This is 
described in the Log4J docs (I believe it's kind of the normal, accepted 
way), and it's how I've personally always done it.  It may make no 
difference at all, but I don't know what the overhead of that 
getLogger() call is, might be interesting to avoid it and see if there 
is any difference.

Frank

Michael A Chase wrote:
> In the most recent update to our system, I installed log4j 1.2.11.  After
> the update someone at our hosting facility finally noticed that the
> application was taking a very long time to paint some screens.  The
> application was frequently painfully slow to begin with, but someone
> latched on to log4j as something that had changed recently.
> 
> In production, the application is calling Logger.getLogger() once for most
> class instantiations (5-10 per screen) and logger.warn() once per screen.
> There is only one appender which uses DailyRollingFileAppender.
> 
> Has anyone seen log4j cause a noticeable performance degradation when
> writing one log entry per screen displayed?
> 

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org