<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div dir="auto" class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><blockquote type="cite" class=""><div class="">On Aug 30, 2021, at 10:57 AM, Ceki Gülcü <<a href="mailto:ceki@qos.ch" class="">ceki@qos.ch</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class="">Responses inline.</div></div></blockquote><div class=""><br class=""></div><blockquote type="cite" class="">Personally, I was quite surprised by:<br class=""><br class="">1) the disappointing performance of the LMAX disruptor.<br class="">2) the non uniform impact of running the benchmark under a hypervisor/virtual CPU.</blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Well, here we will have to just disagree. From my analysis you aren’t measuring the performance of the </div><div class="">disruptor at all. When I ran it under a profiler the disruptor doesn’t even show up. It is all overhead in Log4j’s </div><div class="">PatternLayout coupled with some of the complexities in the way I/O was done to be garbage free. We are </div><div class="">working on correcting that and have seen some promising results. But as long as file I/O is the limiting factor </div><div class="">you really aren’t measuring the performance of the disruptor. </div><div class=""><br class=""></div><div class="">On item 2, I am not sure what you are referring to. I’ve just been running my tests on my MacBook Pro. While </div><div class="">I do see that Logback’s FileAppender has been faster my results for Log4j2 look nothing like yours. FYI, here </div><div class="">are results that I just ran on my MacBook Pro using Log4j 2.15.0-SNAPSHOT. My MacBook Pro says it has 8 </div><div class="">cores.</div><div class=""><br class=""></div><div class="">8 Threads</div><div class=""><div class="">Benchmark Mode Cnt Score Error Units</div><div class="">AsyncWithFileAppenderBenchmark.log4j1File thrpt 10 1409.525 ± 57.006 ops/ms</div><div class="">AsyncWithFileAppenderBenchmark.log4j2AsyncFile thrpt 10 1743.430 ± 51.178 ops/ms</div><div class="">AsyncWithFileAppenderBenchmark.logbackFile thrpt 10 2157.374 ± 49.966 ops/ms</div><div class="">FileAppenderBenchmark.log4j1File thrpt 10 764.812 ± 13.624 ops/ms</div><div class="">FileAppenderBenchmark.log4j2File thrpt 10 2281.328 ± 148.979 ops/ms</div><div class="">FileAppenderBenchmark.logbackFile thrpt 10 1946.389 ± 62.855 ops/ms</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class="">16 Threads</div><div class=""><div class="">Benchmark Mode Cnt Score Error Units</div><div class="">AsyncWithFileAppenderBenchmark.log4j1File thrpt 10 1228.149 ± 76.286 ops/ms</div><div class="">AsyncWithFileAppenderBenchmark.log4j2AsyncFile thrpt 10 1590.441 ± 29.938 ops/ms</div><div class="">AsyncWithFileAppenderBenchmark.logbackFile thrpt 10 1994.770 ± 105.827 ops/ms</div><div class="">FileAppenderBenchmark.log4j1File thrpt 10 825.138 ± 18.012 ops/ms</div><div class="">FileAppenderBenchmark.log4j2File thrpt 10 2231.246 ± 111.451 ops/ms</div><div class="">FileAppenderBenchmark.logbackFile thrpt 10 1884.429 ± 48.463 ops/ms</div></div><div class=""><br class=""></div><div class="">My Mac apparently doesn’t do hyper threading so if that is what you mean I don’t have something handy to </div><div class="">test it on.</div></div><div class=""><br class=""></div><div class="">I will admit that both the results above for both Log4j 1 and Log4j 2 are a bit surprising. Log4j 1’s synchronous </div><div class="">test should be much faster. And Log4j 2’s asynchronous test shouldn’t be much different than the synchronous </div><div class="">test. You can be sure that we are continuing to look at these until we can explain the results better.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">While I will not be ordered around, I remain open to suggestions<br class="">including alternative ways of benchmarking.<br class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I apologize if you felt like I was commanding you to do something. I certainly know better than that.</div><div class=""><br class=""></div><div style="orphans: 2; widows: 2;" class=""><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><span class="" style="-webkit-font-kerning: none;">What I am suggesting is that the whole section above "Comparing log4j, log4j2 and logback” is fine IMO. </span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><span class="" style="-webkit-font-kerning: none;">My issue is that when readers get to the section below there is no mention that what is being benchmarked </span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><span class="" style="-webkit-font-kerning: none;">is asynchronous logging with the queues full. For example, "The above results show that throughput in </span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><span class="" style="-webkit-font-kerning: none;">synchronous logging is actually higher than that of asynchronous logging” would be more clear if you simply </span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;"><span class="" style="-webkit-font-kerning: none;">added “when the number of incoming events exceeds the speed of the appender.” to the end of the sentence.</span></div><div class="" style="margin: 0px; font-stretch: normal; line-height: normal;">Otherwise the casual reader will believe it is truly measuring just the overhead of asynchronous logging.</div></div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">Also, I noticed that you have configured Logback’s FileAppender with a 256KB buffer but left Log4j2’s<br class="">appender at its default of 8KB.<br class=""></blockquote><br class="">This is a fair point. I have modified the configuration files [3] and will run the benchmarks again.<br class=""><br class="">[3] <a href="https://github.com/ceki/logback-perf/commit/9736a37f76492b" class="">https://github.com/ceki/logback-perf/commit/9736a37f76492b</a><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I looked at the commit. I still don’t see <span class="" style="background-color: rgb(255, 255, 255); color: rgb(18, 19, 20);">bufferSize</span><span class="" style="background-color: rgb(255, 255, 255);"><b class="" style="color: rgb(106, 132, 219);">=</b><span class="" style="caret-color: rgb(106, 132, 219);">“</span><font class="">262144”</font> added to the configuration for Log4j2.</span></div><div class=""><br class=""></div>Ralph</div></body></html>