Benchmarks were using an unpublished version of logback that works differently than the release version I tested against -- continuing the conversation there, but I'll report back here once dust settles. Rerunning the benchmarks with a logback snapshot from source shows that async logback with one logging thread outperforms async log4j2 with 1 logging thread, however log4j2 performs better with 20 threads. I still need to do a bit of deeper investigation but will be busy with work for the next several hours.
On Fri, Aug 20, 2021, at 12:10, Ralph Goers wrote: > Feel free to respond to his tweet. > > Ralph > > > On Aug 20, 2021, at 7:15 AM, Carter Kozak <[email protected]> wrote: > > > > Thanks for flagging this! I've responded to the tweet, copying it here as > > well for posterity: > > > > Looking at the logback benchmark it appears that no bytes are being written > > to target/test-output/logback-async-perf.log. Upon closer inspection the > > logback asyncappender is in an started=false state, rejecting all input > > events. > > https://twitter.com/carter_kozak/status/1428721705464238085?s=20 > > > > -ck > > > > On Fri, Aug 20, 2021, at 01:13, Volkan Yazıcı wrote: > >> Hello, > >> > >> Ceki has recently posted a Tweet stating that both log4j 1 and logback > >> performs better than log4j 2 in async mode: > >> > >> https://twitter.com/ceki/status/1428461637917360131?s=19 > >> https://github.com/ceki/logback-perf > >> > >> I don't know much about how async wiring is done under the hood, yet, if > >> his claim is true, that is pretty concerning. Would anybody mind sparing > >> some time to investigate if the configuration he employs is tuned good > >> enough and the results are accurate, please? > >> > >> Kind regards. > >> > > >
