LOG4J2-1297 added initial performance test results: synchronous logging throughput
Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/7730ae5e Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/7730ae5e Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/7730ae5e Branch: refs/heads/LOG4j2-494 Commit: 7730ae5eed9b7296e38b9d60578365d2cae9e39b Parents: f226b97 Author: rpopma <[email protected]> Authored: Mon Apr 25 23:44:10 2016 +0900 Committer: Ralph Goers <[email protected]> Committed: Mon Apr 25 21:30:30 2016 -0700 ---------------------------------------------------------------------- .../garbage-free2.6-SyncThroughputLinux.png | Bin 0 -> 70039 bytes src/site/xdoc/manual/garbagefree.xml | 30 +++++++++++++++---- 2 files changed, 25 insertions(+), 5 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/7730ae5e/src/site/resources/images/garbage-free2.6-SyncThroughputLinux.png ---------------------------------------------------------------------- diff --git a/src/site/resources/images/garbage-free2.6-SyncThroughputLinux.png b/src/site/resources/images/garbage-free2.6-SyncThroughputLinux.png new file mode 100644 index 0000000..5de5d9f Binary files /dev/null and b/src/site/resources/images/garbage-free2.6-SyncThroughputLinux.png differ http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/7730ae5e/src/site/xdoc/manual/garbagefree.xml ---------------------------------------------------------------------- diff --git a/src/site/xdoc/manual/garbagefree.xml b/src/site/xdoc/manual/garbagefree.xml index 66cd532..c9e8692 100644 --- a/src/site/xdoc/manual/garbagefree.xml +++ b/src/site/xdoc/manual/garbagefree.xml @@ -352,12 +352,32 @@ public void garbageFree() { </subsection> <a name="Performance" /> <subsection name="Performance"> - <a name="Latency" /> - <h4>TBD what to include here</h4> - <p>Async Loggers 2.5 vs 2.6 in garbage-free mode</p> - <p>Log4j 2.6 synchronous logging "classic" versus garbage-free mode - impact of adding threads</p> - <p>Comparison with other logging libraries?</p> + <h4>Response Time of Garbage-free Logging is Consistently Better with Fewer Spikes</h4> + <p>TODO: add latency histogram: Response time distribution of Async Loggers 2.5 vs 2.6 in garbage-free mode under various loads.</p> + <p>TODO: add latency histogram: Response time distribution of synchronous logging vs 2.6 in garbage-free mode under various loads.</p> + + <a name="Throughput" /> + <h4>Throughput of Garbage-free Logging May Be Worse (But It's All Relative)</h4> + <p>Log4j 2.6 in garbage-free mode has the highest throughput in single-threaded scenarios. In multi-threaded + scenarios, Log4j 2.6 "classic" has highest throughput, with Log4j 2.6 in garbage-free mode and Log4j 2.5 + not far behind. Our test results suggest that the throughput of all other logging frameworks rapidly + declines in multi-threaded applications.</p> + <p>The graph below compares Log4j 2.6 in garbage-free mode to Log4j 2.6 "classic" mode (which allocates + temporary objects for every logging call), Log4j 2.5, Log4j 1.2.17, Logback 1.1.7 and + Java util logging (JUL) on Oracle Java 1.8.0_45. All Log4j 2.x results use the RandomAccessFile appender. + Log4j 1.2.17, Logback and JUL use their respective File appenders. ImmediateFlush was set to <tt>false</tt> for all + loggers that support this. The JUL results are for the <tt>XMLFormatter</tt> (which in our measurements was + about twice as fast as the <tt>SimpleFormatter</tt>).</p> + <p>The synchronous logging throughput results below are generated with the + <a href="http://openjdk.java.net/projects/code-tools/jmh/">JMH</a> Java benchmark harness. + See the <tt>org.apache.logging.log4j.perf.jmh.FileAppenderBenchmark</tt> source code in the log4j-perf module.</p> + <p><img src="../images/garbage-free2.6-SyncThroughputLinux.png" + alt="Throughput of Log4j 2.6 in garbage-free mode is slightly worse than in classic mode, but on par with 2.5 and much better than alternatives logging libraries" /></p> + <p>(TODO: DOUBLE-CHECK) The above results are for <em>synchronous</em> logging. For <em>asynchronous</em> logging, + there was no measurable difference in throughput between + Log4j 2.6 in garbage-free mode and Log4j 2.6 in "classic" mode (allocating + new objects on every logging call).</p> </subsection> <a name="UnderTheHood" /> <subsection name="Under the Hood">
