You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Remko Popma (JIRA)" <ji...@apache.org> on 2013/07/29 09:15:49 UTC
[jira] [Comment Edited] (LOG4J2-324) Potential performance
improvement for StatusLogger
[ https://issues.apache.org/jira/browse/LOG4J2-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13722221#comment-13722221 ]
Remko Popma edited comment on LOG4J2-324 at 7/29/13 7:14 AM:
-------------------------------------------------------------
I see. In that case the statusLevel idea is still viable, but we may need to review all usage of StatusLogger: perhaps make changes to use INFO level for only-once initialization messages. (I have the impression that many components currently use StatusLogger#debug for both (only once) initialization and (repeating) debug-level messages.)
By the way, if the message logged is a ParameterizedMessage and not a SimpleMessage (as is the case in FlumeAvroManager), the StatusData object uses 470+ bytes per instance.
was (Author: remkop@yahoo.com):
I see. In that case the statusLevel idea is still viable, but we may need to review all usage of StatusLogger: perhaps make changes to use INFO level for only-once initialization messages. (I have the impression that many components currently use StatusLogger#debug for both initialization and debug-level messages.)
By the way, if the message logged is a ParameterizedMessage and not a SimpleMessage (as is the case in FlumeAvroManager), the StatusData object uses 470+ bytes per instance.
> Potential performance improvement for StatusLogger
> --------------------------------------------------
>
> Key: LOG4J2-324
> URL: https://issues.apache.org/jira/browse/LOG4J2-324
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
> Affects Versions: 2.0-beta8
> Reporter: Remko Popma
>
> From discussion on the mailing list - please feel free to edit this description.
> From: Ralph Goers
> To: Log4J Developers List <lo...@logging.apache.org>
> Sent: Wednesday, July 24, 2013 7:57 AM
> Subject: Re: Config additions, WAS: Confused: want low latency: do I need BOTH async logger AND async appender??
> I think I just came up with another attribute for the JMX element. I'll have to look at the status logger but I believe it is always creating a StatusData object and putting it in a ring buffer so they can be printed later. This will actually create a lot of objects and will impact performance. So we will want to add a statusLevel attribute to the JMX element to specify what the level is on the events that should be added to the buffer.
> It was actually kind of cool though as the person doing the performance test looked at the JMX stats and even though the status was set to error in the configuration they had lots of debug messages in JMX that were quite helpful to verify a misconfiguration.
> Ralph
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org