Nicolas Filotto created GTNPORTAL-3569:
------------------------------------------
Summary: Reduce the performance impact of the cache of the TemplateService in
a cluster
Key: GTNPORTAL-3569
URL:
https://issues.jboss.org/browse/GTNPORTAL-3569
Project: GateIn Portal
Issue Type: Enhancement
Components: Performance
Affects Versions: 3.8.8.Final
Reporter: Nicolas Filotto
While trying to identify the root cause of the performances regression between JPP 6.1.1
and JPP 6.2, I realized that the bug fix for
https://issues.jboss.org/browse/GTNPORTAL-3410 is actually buggy and causes a significant
performance regression.
It is buggy because as the variable script of the class GroovyTemplate is transient, its
value is not replicated over the cluster so far so good, the problem is that there is no
synchronization mechanism to ensure that the value of this variable will be created only
once even if we have several concurrent threads that try to access to its value, this is a
real issue especially when we know that building the value of this particular variable has
a significant cost.
It causes a significant performance regression because it replaces an eXo Cache based on a
ConcurrentHashMap with an eXo Cache based on ISPN in replicated mode, according to my
micro benchmarks, the get method of a ConcurrentHashMap is 11 times faster than the get
method of ISPN so when we know that the cache of the TemplateService is very frequently
used we know that this configuration change will have a significant impact on
performances
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)