[ 
https://issues.apache.org/jira/browse/LOG4J2-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572991#comment-13572991
 ] 

Remko Popma commented on LOG4J2-163:
------------------------------------

v3 changes
----------
* Added performance tests for multi-threaded usage scenarios
* Increased VM warmup time in performance tests
* Performance test results report: replaced simple average with sampling 
distribution

v2 changes
----------
* API changes for log4j-beta4 (trunk) from beta-3
* Included lmax.disruptor-2.10.4 source to avoid external dependency
* New feature: AsyncLogger now correctly passes configuration properties to log 
events
* RingBuffer size is now configurable with System property 
"AsyncLogger.RingBufferSize"
* Changed default for immediateFlush to true for FastFileAppender and
  RollingFastFileAppender (to be in line with standard *FileAppender)
* Replaced System.out.println with StatusLogger.debug in AsyncLogger
* Changed package name log4j.async to org.apache.logging.log4j.core.async
* Changed package name log4j.appenders to 
org.apache.logging.log4j.core.async.appender
* Formatted all source with spaces instead of tabs
* Added Apache License notice file header to all source files
* Implementations for JIRA items LOG4J2-151, LOG4J2-154 and LOG4J2-157

* To run performance tests (AsyncLoggerPerfTest.bat and SyncLoggerPerfTest.bat),
  you need to supply 
  log4j-api-2.0-beta4-SNAPSHOT.jar and 
  log4j-core-2.0-beta4-SNAPSHOT.jar

Implemented JIRA items:
* LOG4J2-151 (a): changed visibility of method 
              org.apache.logging.log4j.core.LoggerContext#newInstance from
              private to protected (line 330)
              
             (b) changed visibility of method 
              
org.apache.logging.log4j.core.Logger$PrivateConfig#logEvent(LogEvent)
              from protected to public (line 268) 
* LOG4J2-154: - ThreadContext performance improvement: copy the internal
              data structure for every modification, so we don't need to make
              a deep copy when returning an immutable Map or Stack.
              - same for DefaultThreadContextMap
              - added method getImmutableContext to ThreadContextMap:
                a fast implementation of this method is key to performance
* LOG4J2-157: added method 
org.apache.logging.log4j.core.config.LoggerConfig#getProperties
              (line 275)

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

Reply via email to