Return-Path: Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: (qmail 58463 invoked from network); 19 Apr 2010 09:47:54 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 19 Apr 2010 09:47:54 -0000 Received: (qmail 11701 invoked by uid 500); 19 Apr 2010 09:47:53 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 11440 invoked by uid 500); 19 Apr 2010 09:47:51 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 11423 invoked by uid 99); 19 Apr 2010 09:47:50 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Apr 2010 09:47:50 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [129.125.36.248] (HELO chillout.service.rug.nl) (129.125.36.248) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Apr 2010 09:47:42 +0000 Received: from [129.125.249.92] ([172.23.16.211]) (authenticated bits=0) by chillout.service.rug.nl (8.14.4/8.14.4) with ESMTP id o3J9lM8i025762 for ; Mon, 19 Apr 2010 11:47:22 +0200 Message-ID: <4BCC26A9.7030801@rug.nl> Date: Mon, 19 Apr 2010 11:47:21 +0200 From: Dennis van der Laan Organization: University of Groningen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: users@jackrabbit.apache.org Subject: Performance question when clustering Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at chillout X-Virus-Status: Clean X-Virus-Checked: Checked by ClamAV on apache.org Hi all, We are setting up a clustered Jackrabbit environment as the data storage for our (custom) CMS. We are using Jackrabbit 1.6.0 with an Oracle 10g database, bundled persistence manager and finegrained ISM locking. Whenever the repository is accessed through a JcrSession, we first do a session.refresh(). We were assuming clustering would have some overhead, but because of the much-talked-about performance bottleneck in the PersistenceManager and/or SharedItemStateManager, the performance boost would compensate this overhead. What we have observed is that having more cluster nodes using the same Jackrabbit repository has a significant impact on performance, with almost linear degradation. We started a performance test by uploading files to just one machine in a two-machine-cluster and the same test on a six-machine-cluster. The first test was about 3x faster than the second test. Most of the time, the threads are waiting on a Mutex in org.apache.jackrabbit.core.cluster.ClusterNode.sync() (called from SessionImpl.refresh()). Uploading to multiple cluster-machines at the same time only seemed to increase the performance-impact, probably because the time a Mutex is being held is longer due to the fact other nodes in the cluster have updates, too. So my questions are: - Is it a good idea to call session.refresh() every time we use the session? - Is there a difference between calling session.refresh() and the automatic sync done by the ClusterNode thread? - Why is a refresh more expansive when there are more cluster nodes? Thanks for any information! Dennis -- Dennis van der Laan, MSc Centre for Information Technology University of Groningen