[
https://issues.apache.org/jira/browse/LOG4J2-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14935125#comment-14935125
]
Dmitri Blinov commented on LOG4J2-1125:
---------------------------------------
I just noticed that tomcat-7 complains that newly introduced ThreadLocal in 2.4
is not cleaned after web application is being redeployed.
Here is quote from catalina.out
{quote}
SEVERE: The web application created a ThreadLocal with key of type
\[org.apache.logging.log4j.core.layout.PatternLayout$1] (value
\[org.apache.logging.log4j.core.layout.PatternLayout$1@a6bbbd5]) and a value of
type \[java.lang.StringBuilder] (value \[\[2015-09-29 15:00:07,233] \[TRACE]
\[http-bio-8080-exec-694]: SessionLogger.close: Closing logging context:
fx.beta.088F520330A8EB3C604AED2E36D0F811
]) but failed to remove it when the web application was stopped. Threads are
going to be renewed over time to try and avoid a probable memory leak.
{quote}
I think it's very serious and needs to be fixed
> Reuse StringBuilder to improve performance for PatternLayout
> ------------------------------------------------------------
>
> Key: LOG4J2-1125
> URL: https://issues.apache.org/jira/browse/LOG4J2-1125
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
> Affects Versions: 2.3
> Reporter: Remko Popma
> Assignee: Remko Popma
> Fix For: 2.4
>
>
> As part of the investigation for LOG4J2-930 (PatternLayout performance), I
> found that in PatternLayout.toSerializable(), instead of creating a new
> StringBuilder each time this method is called, caching and reusing a
> ThreadLocal<StringBuilder> makes a huge difference in performance.
> *Before (new StringBuilder instance for each event)*
> {code}
> Benchmark Mode Samples
> Score Error Units
> o.a.l.l.p.j.PatternLayoutComparisonBenchmark.log4j2 sample 125646
> 1413.362 ± 33.806 ns/op
> o.a.l.l.p.j.PatternLayoutComparisonBenchmark.logback sample 128680
> 1383.201 ± 33.076 ns/op
> {code}
> *After (reuse ThreadLocal<StringBuilder>)*
> {code}
> Benchmark Mode Samples
> Score Error Units
> o.a.l.l.p.j.PatternLayoutComparisonBenchmark.log4j2 sample 156816
> 1138.547 ± 20.290 ns/op
> o.a.l.l.p.j.PatternLayoutComparisonBenchmark.logback sample 127978
> 1355.166 ± 19.462 ns/op
> {code}
> org.apache.logging.log4j.PerformanceComparison results indicate this improves
> overall performance:
> *Before (new StringBuilder instance for each event)*
> {code}
> Log4j : 1501
> Logback : 1208
> Log4j 2.0: 1646
> ###############################################
> Log4j : 1487
> Logback : 1165
> Log4j 2.0: 1566
> ###############################################
> Log4j : 1490
> Logback : 1170
> Log4j 2.0: 1485
> ###############################################
> Log4j : 1392
> Logback : 1143
> Log4j 2.0: 1629
> {code}
> *After (reuse ThreadLocal<StringBuilder>)*
> {code}
> Log4j : 1498
> Logback : 1202
> Log4j 2.0: 1213
> ###############################################
> Log4j : 1394
> Logback : 1057
> Log4j 2.0: 1290
> ###############################################
> Log4j : 1240
> Logback : 1109
> Log4j 2.0: 1335
> ###############################################
> Log4j : 1310
> Logback : 1146
> Log4j 2.0: 1210
> {code}
> There are more changes for LOG4J2-930, so I am splitting off this item into a
> separate ticket so I can address it and close it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
