Uploaded image for project: 'Drools'
  1. Drools
  2. DROOLS-4252

Kie Drools benchmark tune logging config

    XMLWordPrintable

Details

    • Enhancement
    • Resolution: Done
    • Major
    • None
    • None
    • core engine
    • None
    • 2019 Week 26-28
    • 3
    • NEW
    • NEW

    Description

      I observe that logback config inside Kie Drools benchmark is set with both %method and %line which from the logback manual:

      L / line
      Outputs the line number from where the logging request was issued.

      Generating the line number information is not particularly fast. Thus, its use should be avoided unless execution speed is not an issue.

      ...

      M / method
      Outputs the method name where the logging request was issued.

      Generating the method name is not particularly fast. Thus, its use should be avoided unless execution speed is not an issue.

      In fact case in point for an introduced benchmark the symptom was normal logger/error message caused log of synthetic stacktrace being generated:

      The generation of the synthetic stacktrace by the logback logging framework should not influence the benchmark result, although I wanted to maintain the business logic that error, infos etc still get reported via SLF4j logging.

      Changing the Kie Drools benchmark configuration on the specific benchmark I was chasing after, given an ~9x improvement:

      BASELINE
      Benchmark                                                  (numberOfElements)  (sparseness)  Mode  Cnt   Score   Error  Units
      DMNEvaluateDecisionTablesSparseBenchmark.evaluateDecision                 100            10    ss  250  18.447 ± 0.633  ms/op
      
      AFTER
      Benchmark                                                  (numberOfElements)  (sparseness)  Mode  Cnt  Score   Error  Units
      DMNEvaluateDecisionTablesSparseBenchmark.evaluateDecision                 100            10    ss  250  2.744 ± 0.180  ms/op
      

      I believe the logback config should be changed in order to avoid introducing the degradation of execution time caused just by the logging framework, at least for those use-case when by standard we report Info, Error, etc.

      /cc etirelli mfusco@redhat.com

      Attachments

        Activity

          People

            mmortari@redhat.com Matteo Mortari
            mmortari@redhat.com Matteo Mortari
            Tibor Zimányi Tibor Zimányi
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: