[
https://issues.apache.org/jira/browse/JCR-3721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13895845#comment-13895845
]
Maxim Zinal edited comment on JCR-3721 at 2/9/14 11:21 AM:
-----------------------------------------------------------
One more comment: I was able to (mostly) solve our performance problems by
removing path hierarchy constraints from all but few XPath queries.
Queries without path hierarchy constraints (but with additional property
constraints, which I had to add in order to get the same results as before) run
10-15 times (yes, 1000-1500 percent) faster. For example, initial prefetch job
which we use to fill various application caches took 50 seconds instead of ~780
seconds.
IMHO that's not a very good result for a JCR system, which is hierarchy-based
by its nature.
Our test (and production) database contain ~2 500 000 nodes with the total size
~350 Mbytes, and lucene filesystem indexes occupy ~1 Gb space, if that matters.
was (Author: zinal):
One more comment: I was able to (mostly) solve our performance problems by
removing path hierarchy constraints from all but few XPath queries.
Queries without path hierarchy constraing (but with additional property
constraints, which I had to add in order to get the same results as before) run
10-15 times (yes, 1000-1500 percent) faster. For example, initial prefetch job
which we use to fill various application caches took 50 seconds instead of ~780
seconds.
IMHO that's not a very good result for a JCR system, which is hierarchy-based
by it's nature.
Our test (and production) database contain ~2 500 000 nodes with total size
~350 Mbytes, and lucene filesystem indexes occupy ~1 Gb space, if that matters.
> 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)
