You are viewing a plain text version of this content. The canonical link for it is here.

Posted to issues@metron.apache.org by "Dale Richardson (JIRA)" <ji...@apache.org> on 2019/07/29 05:06:00 UTC

[jira] [Created] (METRON-2196) Performance regressions because of trace / debug logging

Dale Richardson created METRON-2196:
---------------------------------------

             Summary: 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


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)