logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remko Popma (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (LOG4J2-163) Create asynchronous Logger for low-latency logging
Date Mon, 11 Feb 2013 09:03:12 GMT

     [ https://issues.apache.org/jira/browse/LOG4J2-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Remko Popma updated LOG4J2-163:
-------------------------------

    Attachment: FastLog4j-v4-for-beta4.zip

Ralph, please find attached FastLog4j-v4-for-beta4.zip.

While working on this issue I ran into the location issue again: Unconditionally taking stacktrace
element snapshots makes AsyncLoggerConfig three times slower than the standard LoggerConfig
when location is not necessary.

Performance test results (on Windows laptop):
root + %location pattern: ~40 microsec
root without %location:  ~5.4 microsec
asyncRoot (default) : ~15 microsec <-- slower than sync logger without location: LOG4J2-153
needed
asyncRoot + needsLocation=false: 0.6 microsec

This would make AsyncLoggerConfig useless when users don't need location.

So I went ahead and included a solution for LOG4J2-153: add a "needsLocation" attribute to
the logger and asyncLogger config.
The default would be "true", that is, include location information (so it is backwards compatible).

What do you think?


v4 changes
----------
* (LOG4J2-163) Added AsyncLoggerConfig to enable mixing sync and async loggers
Various changes for LOG4J2-163 and LOG4J2-153:
* Added plugin attribute "needsLocation" to both LoggerConfig and AsyncLoggerConfig
* Added method isLocationRequired() to LoggerConfig
* Extracted code from Log4jLogEvent.getSource() into static method
  Log4jLogEvent.calcLocation so it can be re-used in AsyncLogger
* AsyncLogger now includes location StackTraceElement unless 
  config.loggerConfig.isLocationRequired() returns false
* Modified core.Logger$PrivateConfig to make its config and loggerConfig fields
  visible for Logger subclasses
* added methods isLocationRequired/setLocationRequired to interface LogEvent
  and impl classes Log4jLogEvent and RingBufferLogEvent
* Additivity of location in logger hierarchy: in LoggerConfig.log, 
  call LogEvent.setLocationRequired with config "needsLocation" attribute value
* Log4jLogEvent.getSource checks isLocationRequired before initializing stackTraceElement
* (LOG4J2-164) added  methods isEndOfBatch/setEndOfBatch to LogEvent interface
  and impl classes Log4jLogEvent and RingBufferLogEvent.
  (If accepted I'll make follow-up changes to the FastXxxAppender classes.)
* (Misc) Added ExceptionHandler support to AsyncLogger and AsyncLoggerConfig
* (Misc) Bugfix in RingBufferLogEvent

Affected classes:
src/org/apache/logging/log4j/core/LogEvent
src/org/apache/logging/log4j/core/Logger
src/org/apache/logging/log4j/core/async/AsyncLogger
src/org/apache/logging/log4j/core/async/RingBufferLogEvent
src/org/apache/logging/log4j/core/config/LoggerConfig
src/org/apache/logging/log4j/core/config/async/AsyncLoggerConfig
src/org/apache/logging/log4j/core/impl/Log4jLogEvent
perftest/*
test/*

                
> Create asynchronous Logger for low-latency logging
> --------------------------------------------------
>
>                 Key: LOG4J2-163
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-163
>             Project: Log4j 2
>          Issue Type: Improvement
>    Affects Versions: 2.0-beta4
>            Reporter: Remko Popma
>         Attachments: FastLog4j-v2-for-beta4.zip, FastLog4j-v3-for-beta4.zip, FastLog4j-v4-for-beta4.zip
>
>
> One of the main considerations for selecting a logging library is performance, specifically,
how long it takes for a call to Logger.log to return. (See the comments of LOG4J-151 for a
discussion of latency versus application throughput and logging throughput.)
> I believe it is possible to improve this performance by an order of magnitude by having
an asynchronous Logger implementation that hands off the work to a separate thread as early
as possible. The disk I/O would be done in this separate thread. 
> AsynchAppender is not a good match for these requirements, as with that approach (a)
the logging call still needs to flow down the hierarchy to the appender, doing synchronization
and creating objects at various points on the way, and (b) when serializing the LogEvent,
the getSource() method is always called, which is expensive.

--
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


Mime
View raw message