openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Copeland <t...@jotobjects.com>
Subject Re: Slow performance with OpenJPA when selecting from a ManyToMany relation.
Date Sat, 21 Mar 2009 06:21:58 GMT
Nitish -

I have the same question - I guess you cannot release the connection 
while the transaction is open.

In my case I think the Entity Manager will exist for the duration of a 
transaction in a Servlet Request.

- Paul

On 3/20/2009 10:57 PM, Nitish Kumar wrote:
> Hi Michael,
>        The connection retain mode property makes the numbers almost same, but I am a
little confused. Shouldnt this be the default behavior of Entity Manager? Typically I would
have the entity manager tied up to the transaction (JTA or Spring), so I would expect Entity
Manager to hold the connection always.  
>
> Thanks and Regards,
> Nitish Kumar
>
> -----Original Message-----
> From: Michael Dick [mailto:michael.d.dick@gmail.com]
> Sent: Sat 3/21/2009 1:55 AM
> To: users@openjpa.apache.org
> Subject: Re: Slow performance with OpenJPA when selecting from a ManyToMany relation.
>  
> Hi all,
>
> As Paul pointed out privately I didn't indicate which versions of OpenJPA I
> was using. I've been testing with 1.2.0, 1.2.1 and 2.0.0-SNAPSHOT primarily.
> I also ran with 1.3.0-SNAPSHOT, and 1.0.3 for comparison - there wasn't much
> difference though so reduced the scope to 1.2 and trunk.
>
> The testcase uses a single EntityManager instance to issue a batch of findBy
> operations. In OpenJPA each findBy (or any query for that matter) obtains a
> connection from the connection pool and returns it after getting the
> results. So we're spending a lot of time moving the connection to and from
> the pool (some cleanup is done along the way).
>
> Fortunately this behavior can be configured with the
> openjpa.ConnectionRetainMode property. Setting it to "always" causes the
> EntityManager to hold on to a single connection until the EntityManager
> closes. Obviously this setting introduces the possibility of exhausting the
> connection pool if num_entitymanagers > max_connections, but for this
> benchmark it's safe to try.
>
> Setting ConnectionRetainMode gave OpenJPA equivalent times on my laptop at
> 100 - 100,000 iterations. In addition I removed the
> openjpa.jdbc.SynchronizeMappings property from the example (it's extraneous
> once the tables are created anyway).Another option I enabled that made some
> difference was preparedStatementCaching in dbcp. I'm assuming EclipseLink
> has some pstmt caching as well, but that could be faulty - in which case
> I'll disable it in dbcp.
>
> Here's the entire set of properties I'm using :
>         properties.put("openjpa.Log", "DefaultLevel=FATAL");
>         properties.put("openjpa.RuntimeUnenhancedClasses", "unsupported");
>         properties.put("openjpa.ConnectionRetainMode", "always");
>         properties.put("openjpa.ConnectionDriverName",
>             "org.apache.commons.dbcp.BasicDataSource");
>
>         properties.put("openjpa.ConnectionProperties", String.format(
>             "DriverClassName=%s, Url=%s, username=%s, password=%s,"
>                 + " MaxActive=%s, MaxIdle=%s, MinIdle=%s, MaxWait=%s"
>                 + ", poolPreparedStatements=true"
>                 , JDBC_DRIVER, JDBC_URL, JDBC_USER,
>             JDBC_PASSWORD, MAX_CON, MIN_CON, MIN_CON, "1000"));
>
>         EntityManagerFactory factory =
>             Persistence.createEntityManagerFactory("OpenJPAPU", properties);
>
> MIN_CON = 1, MAX_CON=10.
>
> Shubbis, could you try running something similar and see if you get the same
> results?
>
> -mike
>
> On Fri, Mar 20, 2009 at 8:46 AM, Michael Dick <michael.d.dick@gmail.com>wrote:
>
>   
>> Hi, I took a quick run with the source code from the RAR Shubbis attached
>> earlier (thanks BTW).
>>
>> The SQL we execute for this findBy is SELECT t0.warehouseName FROM
>> Warehouse t0 WHERE t0.warehouseNr = ?. Pretty basic, and I doubt EclipseLink
>> is doing better (certainly not 3x) based solely on the SQL.
>>
>> So I started digging deeper and on my laptop (not to be confused with any
>> sort of "real" benchmark) there's a sweet spot around 100 iterations. Under
>> 100 OpenJPA is faster. Between 100 and 125 they're comparable, and over 125
>> iterations EclipseLink starts pulling ahead.
>>
>> Environment :
>> * Entities were enhanced by the PCEnhancer tool prior to running the tests.
>>
>> * Connection pooling is enabled for EclipseLink and OpenJPA with roughly
>> the same settings. EclipseLink's pool and commons-dbcp weren't an easy 1:1
>> match, so I might have some investigation to do there.
>> * MySQL Connector for Java v 5.1.7.
>> * MySQL database running locally, Version: 5.0.67-0ubuntu6
>> * Tests executed in Eclipse, YMMV outside of Eclipse.
>> * Sun JDK 5 java full version "1.5.0_15-b04"
>>
>> I have done a lot of hacking about with the sample application but I don't
>> think I've violated the intent of the exercise. I'll upload the app to a
>> jira shortly.
>>
>> The relevant code is in my pastebin at these links :
>> persistence.xml : http://miked.pastebin.com/m490814b7
>> test01.java : http://miked.pastebin.com/m7d3df62f
>> WarehouseDAO.java : http://miked.pastebin.com/m49ab9a0e
>>
>> I highlighted the changed lines in WarehouseDAO, but missed it on the
>> others (too many lines to highlight accurately.
>>
>> I'm still looking, but thought this was worth sharing in case someone else
>> sees something I've missed.
>>
>> -mike
>>
>>
>>
>> On Thu, Mar 19, 2009 at 10:53 AM, Paul Copeland <tech@jotobjects.com>wrote:
>>
>>     
>>> At one point in this thread it was mentioned that the benchmark ran much
>>> faster on a home computer than on an office computer and the reason for the
>>> difference was not obvious.  Was that difference explained yet?
>>>
>>> What version of OpenJPA is the test using?
>>>
>>> - Paul
>>>
>>>
>>> On 3/19/2009 7:44 AM, 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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>
>>>>         
>>>       
>
>
> -------------------------------------------------------------------------------------------------------------------------
> "The information contained in this e-mail transmission is confidential and may be privileged.
It is intended only for the 
> addressee(s) stated above. If you are not an addressee, any use, dissemination, distribution,
publication, or copying of 
> the information contained in this e-mail is strictly prohibited. If you have received
this e-mail in error, please 
> immediately notify us by telephone (+91 80 6618 6555), or e-mail the sender and delete
the e-mail from your system. 
> If you do not want to receive our emails please let us know so that we may delete you
from our email list. Proteans 
> Software Solutions and its parent group ("CAMO Group") do not accept liability for damage
caused by this email, and may 
> monitor email traffic." 
> -------------------------------------------------------------------------------------------------------------------------
>   


Mime
View raw message