Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 47762 invoked from network); 12 Apr 2010 07:32:07 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 12 Apr 2010 07:32:07 -0000 Received: (qmail 47185 invoked by uid 500); 12 Apr 2010 07:32:07 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 47032 invoked by uid 500); 12 Apr 2010 07:32:06 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 47025 invoked by uid 99); 12 Apr 2010 07:32:05 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Apr 2010 07:32:05 +0000 X-ASF-Spam-Status: No, hits=-1.1 required=10.0 tests=AWL,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [217.32.164.151] (HELO smtp4.smtp.bt.com) (217.32.164.151) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Apr 2010 07:31:57 +0000 Received: from E03MVX1-UKDY.domain1.systemhost.net ([193.113.30.54]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Apr 2010 08:31:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CADA12.2DFD0058" Subject: Jackrabbit 1.6.0 Write Performance Date: Mon, 12 Apr 2010 08:35:14 +0100 Message-ID: <7984D3ED1FAA344FA73D71DC9F54CF2817AB8E11@E03MVX1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Jackrabbit 1.6.0 Write Performance Thread-Index: AcraErCJE9CitnEuSTeIM7KP/I2zAg== From: To: X-OriginalArrivalTime: 12 Apr 2010 07:31:35.0398 (UTC) FILETIME=[2E446060:01CADA12] This is a multi-part message in MIME format. ------_=_NextPart_001_01CADA12.2DFD0058 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi We're running a multi-threaded application which creates/updates nodes in jackrabbit. Here's an outline of the deployment model:- - The jackrabbit web app is deployed to the same tomcat instance as our main app. - The jackrabbit repository is accessed from our app using RMI. - We use Threadlocal to confine/isolate the jackrabbit Session. - We use jackrabbit node locking to enable concurrency of writes to jackrabbit nodes. We have a multiple level node hierarchy where nodes are added concurrently. - We use the embedded Derby database for database persistence. We're getting a bit of a bottleneck when performing the writes, mainly due to the amount of node locking we're having to do. I can't see a way around this, so the only measures I can see to improve the performance is speed up the writes.=20 We've tested using postgres for the database persistence, so hopefully we should get some performance gains there. Is there anything else that can help improve the write performance? E.g. moving back to using the standalone server, rather than co-hosting jackrabbit in the same tomcat container as the app? Regards George Sibley =20 ------_=_NextPart_001_01CADA12.2DFD0058 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jackrabbit 1.6.0 Write Performance

Hi

We're running a multi-threaded = application which creates/updates nodes in jackrabbit. Here's an outline = of the deployment model:-

- The jackrabbit web app is deployed to = the same tomcat instance as our main app.
- The jackrabbit repository is = accessed from our app using RMI.
- We use Threadlocal to = confine/isolate the jackrabbit Session.
- We use jackrabbit node locking to = enable concurrency of writes to jackrabbit nodes. We have a multiple = level node hierarchy where nodes are added concurrently.

- We use the embedded Derby database = for database persistence.

We're getting a bit of a bottleneck = when performing the writes, mainly due to the amount of node locking = we're having to do. I can't see a way around this, so the only measures = I can see to improve the performance is speed up the writes.

We've tested using postgres for the = database persistence, so hopefully we should get some performance gains = there. Is there anything else that can help improve the write = performance? E.g. moving back to using the standalone server, rather = than co-hosting jackrabbit in the same tomcat container as the = app?

Regards


George Sibley

 

------_=_NextPart_001_01CADA12.2DFD0058--