[
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: [email protected]
For additional commands, e-mail: [email protected]
