[
https://issues.apache.org/jira/browse/FREEMARKER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16259713#comment-16259713
]
Shevek commented on FREEMARKER-80:
----------------------------------
Followup: We blew up some hard drives, so we're switching to live generation of
pages. This means that we won't be hitting freemarker on 32 cores any more
until our live userbase scales. But functionally, this release seems good and
fast, thank you for the changes.
Personal note: I remember hitting the same issue with Introspector in an
application of my own, and when I saw this, you had my sympathies. Sometimes a
JDK1.1 API should have stayed in JDK1.1. Thank you again.
> Performance bottleneck (from profiling)
> ---------------------------------------
>
> Key: FREEMARKER-80
> URL: https://issues.apache.org/jira/browse/FREEMARKER-80
> Project: Apache Freemarker
> Issue Type: Bug
> Components: engine
> Affects Versions: 2.3.26-incubating
> Environment: Linux, Java 8
> Reporter: Shevek
>
> Major performance bottleneck running on a 32-core system, limits effective
> number of threads to about 6: PropertyDescriptor.getReadMethod() is
> synchronized, and blocks other threads. Partial stack follows:
> java.beans.PropertyDescriptor.getReadMethod()
> BeanModel.invokeThroughDescriptor()
> BeanModel.get()
> Dot._eval()
> I suspect there's a workaround with using a method call directly in the FTL
> template, but I haven't figured it out yet. However, this is killing our
> performance. With Velocity, at the cost of a slower renderer, we can run all
> 32 cores, and get the job done faster.
> I'm not entirely sure how to figure out which piece of FTL is causing this
> stack.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
