Mailing-List: contact users-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@openjpa.apache.org
Received-SPF: pass (athena.apache.org: domain of
 lists+1214986160035-208411@n2.nabble.com designates 216.139.236.158 as
 permitted sender)
Message-ID: <1237729890428-2517019.post@n2.nabble.com>
Date: Sun, 22 Mar 2009 06:51:30 -0700 (PDT)
From: Shubbis <marius.jones@broadpark.no>
To: users@openjpa.apache.org
Subject: Re: Slow performance with OpenJPA when selecting from a ManyToMany
  relation.
In-Reply-To: <89c0c52c0903190744t56392cftac229b5c588d012@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <1236860524615-2466994.post@n2.nabble.com>
 <1236893446537-2470215.post@n2.nabble.com>
 <1237283760827-2490419.post@n2.nabble.com>
 <1237283840925-2490426.post@n2.nabble.com>
 <1237285058828-2490519.post@n2.nabble.com>
 <1237300057977-2491667.post@n2.nabble.com>
 <1237306184790-2492297.post@n2.nabble.com>
 <1237314632982-2493009.post@n2.nabble.com>
 <61BBA329F6969F41B79EF9E92114FEA70642C31D@PROSRV0001.proteans.local>
 <89c0c52c0903180946u9ae743bw7188abe572e5b8@mail.gmail.com>
 <1237450782721-2501684.post@n2.nabble.com>
 <61BBA329F6969F41B79EF9E92114FEA706496016@PROSRV0001.proteans.local>
 <1237471517243-2503084.post@n2.nabble.com>
 <89c0c52c0903190744t56392cftac229b5c588d012@mail.gmail.com>


Hi Kevin,

All the implementations are run using each framework's default settings.
With only a few exceptions. 
For instance, openjpa needs to enhance files in order to perform as expected
etc. Small changes that do not require in depth knowledge of the frameworks
are allowed.

Not all scenarios are affected, it seems that only test cases that involve
quite a large number of relations is the root of the problem.

I'm afraid i don't have any thought on Trade or SpecJApp as I have no
experience with either.

I ran with the property settings you posted and can inform you that I got no
warnings. We are enhanced ;)

I also appreciate the efforts to help make this project work as intended. We
have one framework as a main priority each, and as you might be able to
tell, i got OpenJPA. So this is kind of my "baby" during this whole exercise
and believe me, I want it to work just as much as you guys.

Like i said to Michael, his suggestion increased the performance and might
be the solution, but I can not be sure untill i get back to the office.

I will of course reply with updates.

Shubbis


Kevin Sutter wrote:
> 
> Shubbis and Nitish,
> Thanks for your efforts.  So, to clarify -- all implementations are using
> similar configurations (ie. connection pooling, caching, enhancement,
> etc)?
> But, the OpenJPA performance is still 3 times slower than the competitors?
> In all of the scenarios?  Or, just with this ManyToMany scenario?  I would
> expect some overhead as compared to iBatis and/or straight JDBC, but
> OpenJPA
> should be competitive (and beat) the Hibernates and EclipseLinks...  Very
> frustrating.  When we do our comparisons with the industry benchmarks
> (Trade
> and SpecJApp), OpenJPA is extremely competitive.
> 
> I have not closely examined your benchmark project, so I don't know how it
> compares to Trade and/or SpecJApp work loads.  Any thoughts on this topic?
> 
> One other thought...  Just to prove that the enhancement processing is
> being
> done and you're not falling into the sub-classing support, could you run
> with the following property?  This will cause your application to
> error-off
> if your Entities are not byte-code enhanced.  We will not fall into the
> sub-classing support which greatly affects the performance.
> 
> <property name="openjpa.RuntimeUnenhancedClasses"
>     value="warn"/>
> 
> It really seems that you are trying to do a fair comparison, and I greatly
> appreciate your efforts.  The last time one of these comparisons was
> posted,
> the benchmark code and process was flawed.  So, I am pleased to see the
> efforts associated with this exercise.
> 
> Our performance lead is out having a baby, so we haven't been able to dig
> into your benchmark to the extent that we would like.  If we can verify
> that
> the enhancement processing is happening, that would be good input.  Thanks
> for your patience.  What kind of timeframe are you under for posting this
> benchmark?
> 
> Thanks,
> Kevin
> 
> On Thu, Mar 19, 2009 at 9:05 AM, Shubbis <marius.jones@broadpark.no>
> wrote:
> 
>>
>> Since we decided to go with vanilla installations of alle the frameworks
>> we
>> have not added the connection pool feature to OpenJPA, until now.
>>
>> The results are sadly not that great. Yes, it's faster and it doesn't run
>> out of connections like before, BUT it's still 3, yes, -three- times
>> slower
>> than Hibernate, EclipseLink, iBatis and regular JDBC when persisting
>> entities with many relations.
>>
>> Clearly this is not the kind of results I was hoping for and I'm quite
>> perplexed as to what to do.
>>
>> Shubbis
>>
>>
>> Nitish Kumar wrote:
>> >
>> > Hi subbis,
>> >       If I let the iteration loop over 5000, I get that exception, It
>> > seems (I am not sure) openjpa is creating a new connection and after a
>> > while mysql runs out of connection. I tried the same code and iteration
>> > loop with a connection pool and it works fine. That should get you
>> > moving as of now, till someone from Open JPA team looks into the issue.
>> >
>> > Thanks and Regards,
>> > Nitish Kumar
>> >
>>
>> --
>> View this message in context:
>> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2503084.html
>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>
>>
> 
> 

-- 
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2517019.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.