[ 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-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org