Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-Id: <AE15527B-FE8A-4EBD-A220-7A718F98B4A0@sptci.com>
From: Rakesh Vidyadharan <rakesh@sptci.com>
To: "users@jackrabbit.apache.org" <users@jackrabbit.apache.org>
In-Reply-To: <c34d2a311002100753g6f053bcbsa154c7c1067df32c@mail.gmail.com>
Content-Type: text/plain;
	charset=us-ascii;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (iPhone Mail 7E18)
Subject: Re: performance
Date: Wed, 10 Feb 2010 10:07:23 -0600
References: <c34d2a311002100610y5285adcata5b6d52ca3f9dc40@mail.gmail.com>
 <e2a35cbc1002100645p779acd45y68c19190fedb2324@mail.gmail.com>
 <c34d2a311002100753g6f053bcbsa154c7c1067df32c@mail.gmail.com>

If you are going to do a lot of writes, the filesystem option may turn  
out to be terribly slow.  That was my experience on OS X importing  
around 40000 nodes.

Rajesh

On Feb 10, 2010, at 9:53 AM, Luiz Fernando Teston <feu.teston@caravelatech.com 
 > wrote:

> Guo,
>
> Just curious that is there any performance difference between query
>> languages: xpath, sql, JCR-SQL2, JCR-JQOM?
>>
>> I don't know. I'm using only xpath
>
>
>> The default repository configuration is already very optimized: embed
>> derby + file store. You cannot get better performance by using remote
>> db such as mysql.
>>
> I'm trying it with postgresql, but gonna test also with file system  
> to see
> if it improves the performance or not.
>
> Write to disk is much expensive than read in general, so it's
>> expected. Repository is best for content system, assume most action
>> are read operation, hope your stress test reflect the read/write
>> radio. You could aggressively improve read performance by add a cache
>> layer in your application if applicable.
>>
>
> We cache information a lot when possible. But this stress test I'm  
> running
> will be a massive import. So it has lots of writes and also some  
> queries to
> avoid duplicate data. It's a very uncommon scenario.
>
> Thanks for the feedback!
>
>
> Teston
>
>
>>
>> -Guo
>>