> I could submit a zip including the tests and a persistence.xml tomorrow, i
guess.
That would probably be the most expedient way to figure out what is going
on.

> Does anyone on the openjpa dev team run such performance tests?
We don't have anything (that I'm aware of) that runs as part of our builds.
You are correct that it would be easy enough write a smallish benchmark root
out potential regressions ... if someone invested the time. That being said,
we're continually assessing the performance of OpenJPA to ensure that it is
competitive with other providers.

On Mon, Sep 12, 2011 at 2:12 PM, Michael Pflueger
<michael.pflue...@sma.de>wrote:

> Hi, here's the code:
>
>                em = emf.createEntityManager();
>                CriteriaBuilder cb = em.getCriteriaBuilder();
>                CriteriaQuery<TestEntity> cqte =
> cb.createQuery(TestEntity.class);
>                Root<TestEntity> rte = cqte.from(TestEntity.class);
>                TypedQuery<TestEntity> qte =
> em.createQuery(cqte).setMaxResults(2000000);
>                long queryTime = System.currentTimeMillis();
>                List<TestEntity> entities = qte.getResultList();
>                int cnt = 0;
>                long sum = 0;
>                for(TestEntity te : entities) {
>                        cnt++;
>                        sum += te.getId();
>                        if(cnt % 2000 == 0) {
>                                em.clear();
>                        }
>                }
>                //<code to output query time>
>
> TestEntity just has that single ID attribute.
> I could submit a zip including the tests and a persistence.xml tomorrow, i
> guess.
>
> Does anyone on the openjpa dev team run such performance tests?
> I guess those could be automated and run regularly against trunk so
> regressions are spotted quickly.
>
> Michael
>
> -----Ursprüngliche Nachricht-----
> Von: Rick Curtis [mailto:curti...@gmail.com]
> Gesendet: Montag, 12. September 2011 20:44
> An: users@openjpa.apache.org
> Betreff: Re: Speed of fetching simple entities using OpenJPA
>
> Michael -
>
> I wouldn't expect to see that large of a difference of JPA vs JDBC. Can you
> describe your scenario a little better? Are you issuing just a single JPQL
> to select all of your Entities?
>
> Thanks,
> Rick
>
> On Mon, Sep 12, 2011 at 1:36 PM, Michael Pflueger
> <michael.pflue...@sma.de>wrote:
>
> > Hi,
> > I compared JDBC and OpenJPA speed of fetching simple entities (consisting
> > only of a single ID attribute). The speed difference seems quite severe.
> >
> > With JDBC, I can read 2 million entities in about 3 seconds when OS/DB
> > caches are warm.
> > With OpenJPA using slice (a single slice), it takes a bit above 30
> seconds,
> > so about ten times as long, more than I would expect.
> > Using a direct connection without slice reduces this time to about 24
> > seconds, ~8 times as much as the JDBC version.
> >
> > In the JDBC test I also create objects from the rows, so both tests
> include
> > object creation overhead of the entities (plus a sum calculation of the
> > IDs).
> >
> > I'm doing this test using PostgreSQL and an up to date OpenJPA 2.2
> > snapshot.
> > Entities are enhanced using javaagent enhancement.
> >
> > I tried optimizing OpenJPA performance with:
> >      <property name="openjpa.ConnectionRetainMode"
> > value="always"></property>
> >      <property name="openjpa.ProxyManager" value="TrackChanges=false"/>
> >      <property name="openjpa.IgnoreChanges" value="true"/>
> >      <property name="openjpa.LockManager" value="none"/>
> >      <property name="openjpa.DetachState"
> > value="fetch-groups(DetachedStateField=false)"/>
> >
> > But those didn't seem to affect performance in any significant way.
> >
> > Now, is such a large performance hit expected, and what would be the
> > reason?
> > It would be nice if some performance numbers like these would be in the
> > documentation, by the way, to be better able to judge for what
> applications
> > OpenJPA can be used/what performance penalties one has to expect,
> depending
> > on the situation.
> >
> > Regards,
> > Michael
> > ___________________________________________________
> >
> > SMA Solar Technology AG
> > Aufsichtsrat: Guenther Cramer (Vorsitzender)
> > Vorstand: Juergen Dolle, Roland Grebe, Uwe Hertel, Pierre-Pascal Urbon,
> > Marko Werner
> > Handelsregister: Amtsgericht Kassel HRB 3972
> > Sitz der Gesellschaft: 34266 Niestetal
> > USt-ID-Nr. DE 113 08 59 54
> > WEEE-Reg.-Nr. DE 95881150
> > ___________________________________________________
> >
> >
>
>
> --
> *Rick Curtis*
>



-- 
*Rick Curtis*

Reply via email to