[
https://issues.apache.org/jira/browse/HADOOP-16206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17317384#comment-17317384
]
Ahmed Hussein edited comment on HADOOP-16206 at 4/8/21, 6:05 PM:
-----------------------------------------------------------------
{quote}So you suggest we do a benchmark first to get a clear evidence of
performance gains in log4j2, and then start our work? Or you mean we could just
start the work as you think we'd better fully move to log4j2?{quote}
The reason I was talking about performance evaluation is that quite often,
there is a bias when presenting numbers of a new implementations.
As long as there are different resources acknowledging the [performance gains
of log4j2|https://logging.apache.org/log4j/log4j-2.2/performance.html], then it
should be fine to move forward. There is no need to re-invent the wheel.
I believe the garbage-free option is an interesting feature to use to reduce
the objects allocation. This leads to less Garbage collection events.
After log4j2 is in, we can use heap analysis to evaluate different
configurations like garbage-free options.
I agree with [[email protected]]'s that it is good to know the performance
with different log configurations. This probably can be done separately in a
benchmark to get an approximate estimate of the tradeoffs.
I am little bit hesitated to work on this issue as I have started on replacing
Guava APIs several months ago and it won't make sense to have such two big
migrations on one plate.
was (Author: ahussein):
{quote}So you suggest we do a benchmark first to get a clear evidence of
performance gains in log4j2, and then start our work? Or you mean we could just
start the work as you think we'd better fully move to log4j2?{quote}
The reason I was talking about performance evaluation is that quite often,
there is a bias when presenting numbers of a new implementations.
As long as there are different resources acknowledging the [performance gains
of log4j2|https://logging.apache.org/log4j/log4j-2.2/performance.html], then it
should be fine to move forward. There is no need to re-invent the wheel.
I believe the garbage-free option is an interesting feature to use to reduce
the objects allocation. This leads to less Garbage collection events.
After log4j2 is in, we can use heap analysis to evaluate different
configurations like garbage-free options.
I agree with Steve that it is good to know the performance with different log
configurations. This probably can be done separately in a benchmark to get an
approximate estimate of the tradeoffs.
I am little bit hesitated to work on this issue as I have started on replacing
Guava APIs several months ago and it won't make sense to have such two big
migrations on one plate.
> Migrate from Log4j1 to Log4j2
> -----------------------------
>
> Key: HADOOP-16206
> URL: https://issues.apache.org/jira/browse/HADOOP-16206
> Project: Hadoop Common
> Issue Type: Sub-task
> Affects Versions: 3.3.0
> Reporter: Akira Ajisaka
> Priority: Major
> Attachments: HADOOP-16206-wip.001.patch
>
>
> This sub-task is to remove log4j1 dependency and add log4j2 dependency.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
