Re: Cek's new log4j vs logback benchmark

[Carter Kozak]

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

Re: Cek's new log4j vs logback benchmark

[Ralph Goers]

Feel free to respond to his tweet. 

Ralph

> On Aug 20, 2021, at 7:15 AM, Carter Kozak  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.
>> 

Re: Cek's new log4j vs logback benchmark

[Carter Kozak]

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

Re: Cek's new log4j vs logback benchmark

[Ralph Goers]

I don’t understand. His async configuration for Log4j 2 isn’t async. I didn’t 
see him set the system property. The log4j2 config file says


But he didn’t configure an AsyncLogger or AsyncRoot and there is no Async 
Appender configured.

Ralph

> On Aug 20, 2021, at 9:14 AM, Carter Kozak  wrote:
> 
> 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  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.
 
>> 
>> 
>> 

Re: Cek's new log4j vs logback benchmark

[Carter Kozak]

The benchmark itself sets the system property to opt into 
AsyncLoggerContextSelector:
https://github.com/ceki/logback-perf/blob/5f6b10693959b6ecf1b82abddb052e89fe063e89/src/main/java/ch/qos/logback/perf/AsyncWithFileAppenderBenchmark.java#L61
 


There’s some discussion on 
https://gist.github.com/carterkozak/891ea382a12782b772571059d62d501a 


-ck

> On Aug 20, 2021, at 8:04 PM, Ralph Goers  wrote:
> 
> I don’t understand. His async configuration for Log4j 2 isn’t async. I didn’t 
> see him set the system property. The log4j2 config file says
> 
> 
> But he didn’t configure an AsyncLogger or AsyncRoot and there is no Async 
> Appender configured.
> 
> Ralph
> 
>> On Aug 20, 2021, at 9:14 AM, Carter Kozak  wrote:
>> 
>> 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  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.
> 
>>> 
>>> 
>>> 
> 

Re: Cek's new log4j vs logback benchmark

[Matt Sicker]

Does it help that we have five different ways to do async logging?

Matt Sicker

> On Aug 20, 2021, at 19:19, Carter Kozak  wrote:
> 
> The benchmark itself sets the system property to opt into 
> AsyncLoggerContextSelector:
> https://github.com/ceki/logback-perf/blob/5f6b10693959b6ecf1b82abddb052e89fe063e89/src/main/java/ch/qos/logback/perf/AsyncWithFileAppenderBenchmark.java#L61
>  
> 
> 
> There’s some discussion on 
> https://gist.github.com/carterkozak/891ea382a12782b772571059d62d501a 
> 
> 
> -ck
> 
>> On Aug 20, 2021, at 8:04 PM, Ralph Goers  wrote:
>> 
>> I don’t understand. His async configuration for Log4j 2 isn’t async. I 
>> didn’t see him set the system property. The log4j2 config file says
>> 
>> 
>> But he didn’t configure an AsyncLogger or AsyncRoot and there is no Async 
>> Appender configured.
>> 
>> Ralph
>> 
 On Aug 20, 2021, at 9:14 AM, Carter Kozak  wrote:
>>> 
>>> 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  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.
>> 
 
 
 
>> 
> 

Re: Cek's new log4j vs logback benchmark

[Ralph Goers]

Carter,

Thanks for following up. I knew I had to be missing something. I don’t know why 
I didn’t see the system property being set.

Ralph

> On Aug 20, 2021, at 5:19 PM, Carter Kozak  wrote:
> 
> The benchmark itself sets the system property to opt into 
> AsyncLoggerContextSelector:
> https://github.com/ceki/logback-perf/blob/5f6b10693959b6ecf1b82abddb052e89fe063e89/src/main/java/ch/qos/logback/perf/AsyncWithFileAppenderBenchmark.java#L61
>  
> 
> 
> There’s some discussion on 
> https://gist.github.com/carterkozak/891ea382a12782b772571059d62d501a 
> 
> 
> -ck
> 
>> On Aug 20, 2021, at 8:04 PM, Ralph Goers  wrote:
>> 
>> I don’t understand. His async configuration for Log4j 2 isn’t async. I 
>> didn’t see him set the system property. The log4j2 config file says
>> 
>> 
>> But he didn’t configure an AsyncLogger or AsyncRoot and there is no Async 
>> Appender configured.
>> 
>> Ralph
>> 
>>> On Aug 20, 2021, at 9:14 AM, Carter Kozak  wrote:
>>> 
>>> 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  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.
>> 
 
 
 
>> 
>