[
https://issues.apache.org/jira/browse/JCR-3721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Zinal updated JCR-3721:
-----------------------------
Description:
I performed some JackRabbit profiling while trying to investigate the reason of
low performance of our application.
The mostly interesting thing I've found is that NodeId.toString() method is
heavily used for hierarchy-based XPath queries, and it performs really bad.
This are the numbers for my test application:
- Total CPU time: 879 178 msec
- CPU time in NodeId.toString(), including subcalls: 223 705 msec
A quick check against NodeId.toString() implementation shows that it is based
on UUID.toString(), which itself is very ineffective in both in Oracle and IBM
JDK.
I've wrote a quick replacement for this method, and my measurements show that
overall performance became significantly better for our case.
Hope that this will help to improve JackRabbit performance for similiar
applications.
P.S. Another interesting thing I've found is that a lot of time is spent inside
log4j.Category.getEffectiveLevel() method - I suspect this is caused by
numerous log.debug() calls without proper isDebugEnabled() handling.
was:
I performed some JackRabbit profiling while trying to investigate the reason of
low performance of our application.
The mostly interesting thing I've found is that NodeId.toString() method is
heavily used for hierarchy-based XPath queries, and it performs really bad.
This are the numbers for my test application:
- Total CPU time: 879 178 msec
- CPU time in NodeId.toString(), including subcalls: 223 705 msec
A quick check against NodeId.toString() implementation shows that it is based
on UUID.toString(), which itself is very ineffective in both in Oracle and IBM
JDK.
I've wrote a quick replacement for this method, and my measurements show that
overall performance became significantly better for our case.
Hope that this will help to improve JackRabbit performance for similiar
applications.
> Slow and actively called NodeId.toString()
> ------------------------------------------
>
> Key: JCR-3721
> URL: https://issues.apache.org/jira/browse/JCR-3721
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 2.6.5, 2.7
> Environment: Debian/GNU Linux 7.3 / Oracle JDK 7 / Apache Tomcat 7.0;
> Windows Server 2008 / IBM WebSphere AppServer 7.0
> Reporter: Maxim Zinal
> Attachments: NodeIdToString.patch
>
>
> I performed some JackRabbit profiling while trying to investigate the reason
> of low performance of our application.
> The mostly interesting thing I've found is that NodeId.toString() method is
> heavily used for hierarchy-based XPath queries, and it performs really bad.
> This are the numbers for my test application:
> - Total CPU time: 879 178 msec
> - CPU time in NodeId.toString(), including subcalls: 223 705 msec
> A quick check against NodeId.toString() implementation shows that it is based
> on UUID.toString(), which itself is very ineffective in both in Oracle and
> IBM JDK.
> I've wrote a quick replacement for this method, and my measurements show that
> overall performance became significantly better for our case.
> Hope that this will help to improve JackRabbit performance for similiar
> applications.
> P.S. Another interesting thing I've found is that a lot of time is spent
> inside log4j.Category.getEffectiveLevel() method - I suspect this is caused
> by numerous log.debug() calls without proper isDebugEnabled() handling.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
