[
https://issues.apache.org/jira/browse/METRON-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16895200#comment-16895200
]
Otto Fowler commented on METRON-2196:
-------------------------------------
Duplicate. I'll note your comments in that issue
> Performance regressions because of trace / debug logging
> --------------------------------------------------------
>
> Key: METRON-2196
> URL: https://issues.apache.org/jira/browse/METRON-2196
> Project: Metron
> Issue Type: Bug
> Affects Versions: 0.7.1
> Reporter: Dale Richardson
> Priority: Minor
>
> Trace logging messages such as at
> [https://github.com/apache/metron/blob/master/metron-platform/metron-writer/metron-writer-storm/src/main/java/org/apache/metron/writer/hdfs/HdfsWriter.java#L127]
> are causing a performance regression due to the logging function arguments
> not being lazily evaluated (the logging string *is* lazily constructed, but
> largeObject.toJsonString() calls are being evaluated (with all the
> performance and GC overhead) even if the log message is not going to be
> emitted due to the configured log level.
> Potential fixes include:
> # "If" statements around logging messages, testing for log level before
> proceeding
> # Using native java logging with slf4j bridge with JDK8+ which supports
> lazily evaluating logging method parameters.
> # Upgrade slf4j to version 2.x which supports lazily evaluating logging
> method parameters.
> # Create or use an existing custom log function wrapper around our existing
> slf4j 1.x version that will support lazily evaluation of logging method
> parameters.
> Options 2 or 3 is the architecturally cleaner solutions. Option 4 is the
> lightest touch solution classpath wise. Option 1 should not be considered by
> anybody who values the lives of kittens.
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
