Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Date: Mon, 10 Feb 2014 19:31:19 +0000 (UTC)
From: "Jukka Zitting (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Message-ID: <JIRA.12692724.1391362528556.18606.1392060679768@arcas>
In-Reply-To: <JIRA.12692724.1391362528556@arcas>
References: <JIRA.12692724.1391362528556@arcas>
Subject: [jira] [Updated] (JCR-3721) Slow and actively called
 NodeId.toString()
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/JCR-3721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jukka Zitting updated JCR-3721:
-------------------------------

    Fix Version/s: 2.6.6

Merged to the 2.6 branch in revision 1566708.

> 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
>            Assignee: Jukka Zitting
>             Fix For: 2.6.6, 2.7.5
>
>         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)