jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Reutegger (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3721) Slow and actively called NodeId.toString()
Date Mon, 10 Feb 2014 08:49:23 GMT

    [ https://issues.apache.org/jira/browse/JCR-3721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896328#comment-13896328

Marcel Reutegger commented on JCR-3721:

Slower evaluation of hiearchy constraints is one of the trade offs we had to make
when Jackrabbit was designed. Move operstions with Jackrabbit are very fast, but
the downside is that there is no path index for the query engine to use. This means
hierarchy constraints are more expensive compared to simple property constraints
because lucene is not aware of the hierarchy and had to be modeled on top of it.

See also the adaptTo() [presentation|http://www.pro-vision.de/content/medialib/pro-vision/production/adaptto/2012/adaptto2012-efficient-content-structures-and-queries-in-crx-marc/_jcr_content/renditions/rendition.file/adaptto2012-efficient-content-structures-and-queries-in-crx-marcel-reutegger.pdf]
about efficient queries.

> 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()

This message was sent by Atlassian JIRA

View raw message