[ https://issues.apache.org/jira/browse/METRON-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16895210#comment-16895210 ]
Dale Richardson commented on METRON-2196: ----------------------------------------- Thanks. I updated the PR to lodge against original 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)