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

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

I compared performance of log4j2-async with log4j-1.x and logback:
Log4j2-async is significantly faster, especially in multi-threaded scenarios.

1 thread: 20% faster, 2 threads: 45% faster, 4 threads: 2.5x faster, 8 threads: 
3.2x faster

Throughput in logged messages per second:
____________________________    1 thread        2 threads       4 threads       
8 threads
Log4j2: All async (SysClock)    2,652,412       909,119 776,993 516,365
Log4j2: Async Appender _____    1,713,429       603,019 331,506 149,408
Log4j1: Async Appender _____    2,239,664       494,470 221,402 109,314
Logback: Async Appender ____    2,206,907       624,082 307,500 160,096
                                
Log4j2: Sync    273,536 136,523 67,609  34,404
Log4j1: Sync    326,894 105,591 57,036  30,511
Logback: Sync   178,063 65,000  34,372  16,903

For synchronous logging, I experimented with replacing DatePatternConverter 
with a dummy impl, but this only increased throughput to 287,113 ops/sec.

                
> 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, LOG4J2-163-log4j-async-20130320.patch, 
> LOG4J2-163-log4j-async.patch
>
>
> 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

Reply via email to