deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Andraschko <andraschko.tho...@gmail.com>
Subject Re: Performance of DeltaSpike Data
Date Thu, 08 Jun 2017 08:36:17 GMT
I did a major improvement and in my tests, both plain JPA and DS Data are
now very similar.
Would be great if you could provide the new numbers.

2017-06-07 14:33 GMT+02:00 Thomas Andraschko <andraschko.thomas@gmail.com>:

> Hi,
>
> could you please try to run your test again against the github master?
> I already did a small improvement and refactored a little bit on the
> weekend.
>
> 2017-06-06 8:54 GMT+02:00 Schäfer, Johannes <jschaefer@psi.de>:
>
>> Hi,
>>
>> So after the a long weekend, I'm back with my results.
>> For the write, findByPK and findAll tests I get now good numbers.
>> See:
>> https://github.com/johannesschaefer/javaee_jsf_cdi_jpa_data_
>> ds_project_template/blob/master/src/test/java/de/psi/
>> metals/futurelab/repo/benchmark/SaveTest.java
>> https://github.com/johannesschaefer/javaee_jsf_cdi_jpa_data_
>> ds_project_template/blob/master/src/test/java/de/psi/
>> metals/futurelab/repo/benchmark/ReadTest.java
>> https://github.com/johannesschaefer/javaee_jsf_cdi_jpa_data_
>> ds_project_template/blob/master/src/test/java/de/psi/
>> metals/futurelab/repo/benchmark/ReadAllTest.java
>>
>> The difference between delta spike and plain EM are just a few percent,
>> in both directions ;-) .
>>
>> But I wrote a new test case were I try to find entities by an query.
>> https://github.com/johannesschaefer/javaee_jsf_cdi_jpa_data_
>> ds_project_template/blob/master/src/test/java/de/psi/
>> metals/futurelab/repo/benchmark/ReadQueryTest.java
>> So I compare
>>             TypedQuery< Material > query = eml.createQuery(
>>                 "SELECT m FROM Material m WHERE grade = :grade AND width
>> = :width AND thickness = :thickness",
>>                 Material.class );
>>             query.setParameter( "grade", "AAA" );
>>             query.setParameter( "width", 5 );
>>             query.setParameter( "thickness", 5. );
>> List< Material > mats = query.getResultList();
>>
>> to
>> List< Material > mats = matRepo.findByGradeAndWidthAndThickness( "AAA",
>> 5, 5. );
>>
>> Here again the difference is quite high.
>> |   | iter 10    | iter 20    | iter 40    | iter 80    | iter 160   |
>> iter 320   | iter 640   | iter 1280  | iter 2560  | iter 5120   | iter
>> 10240  |
>> |===========================================================
>> ============================================================
>> =============================|
>> | DS| 0.03988012 | 0.151870613| 0.144881044| 0.270389952| 0.526700787|
>> 1.023574545| 1.806960223| 3.426772405| 6.969935385| 13.963582543|
>> 26.785764953|
>> | EM| 0.010984804| 0.021940339| 0.059921297| 0.087386918| 0.171045079|
>> 0.375059016| 0.747171594| 1.560946145| 2.968347174| 6.446844753 |
>> 12.361550486|
>>
>> So as you can see the DeltaSpike implementation needs at least the double
>> amount of time.
>>
>> Any hints for improving the performance?
>>
>> Regards,
>> Johannes
>>
>> -----Original Message-----
>> From: Schäfer, Johannes [mailto:jschaefer@psi.de]
>> Sent: Thursday, June 1, 2017 2:27 PM
>> To: users@deltaspike.apache.org
>> Subject: RE: Performance of DeltaSpike Data
>>
>> Right. Copy and paste error.
>> I added also a flush to the EM test.
>> Now I have similar numbers.
>> ____________________________________________________________
>> ____________________________________________________________
>> ______________________________
>> |   | iter 10    | iter 20    | iter 40    | iter 80    | iter 160   |
>> iter 320   | iter 640   | iter 1280  | iter 2560  | iter 5120   | iter
>> 10240   |
>> |=======================================================================
>> |=======================================================================
>> |=======|
>> | DS| 0.001588214| 0.004130191| 0.007351854| 0.014062036| 0.048373222|
>> | DS| 0.593463008| 0.741351593| 1.697058004| 6.049719288| 34.101109279|
>> | DS| 101.589077365|
>> | EM| 0.001385601| 0.002662861| 0.004092937| 0.108730649| 0.046299193|
>> | EM| 0.106900289| 0.461147505| 1.688040769| 5.960683928| 25.604583163|
>> | EM| 106.688041149|
>>
>> It's a little bit strange for me, why I have to compare
>> EntityPersistenceRepository.save with a em.persist + em.flush. I would
>> expect that an simple EntityPersistenceRepository.save don't have a
>> flush (there is a separate EntityPersistenceRepository.saveAndFlush).
>>
>> When I do a run with EntityPersistenceRepository.saveAndFlush I get the
>> following numbers.
>> ____________________________________________________________
>> ____________________________________________________________
>> ______________________________
>> |   | iter 10    | iter 20    | iter 40    | iter 80    | iter 160   |
>> iter 320   | iter 640   | iter 1280  | iter 2560  | iter 5120   | iter
>> 10240   |
>> |=======================================================================
>> |=======================================================================
>> |=======|
>> | DS| 0.001703015| 0.003457728| 0.008079817| 0.019099994| 0.053865065|
>> | DS| 0.940319597| 0.643245399| 2.292716685| 9.902395587| 40.84301017 |
>> | DS| 172.179435413|
>> | EM| 0.001677545| 0.004168205| 0.005779986| 0.014491211| 0.031066334|
>> | EM| 0.110747277| 0.4051742  | 1.925682412| 5.842606084| 23.540393571|
>> | EM| 132.817886521|
>>
>> So I have the feeling that there is still something wrong.
>>
>> Thanks to Gerhard for his additional hints.
>> I committed all changes to the github repo.
>>
>> Regards,
>> Johannes
>>
>> -----Original Message-----
>> From: Gerhard Petracek [mailto:gpetracek@apache.org]
>> Sent: Thursday, June 1, 2017 1:21 PM
>> To: users@deltaspike.apache.org
>> Subject: Re: Performance of DeltaSpike Data
>>
>> @johannes:
>> as mentioned yesterday you have to move EntityTransaction#begin and
>> EntityTransaction#commit into the for-loop.
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2017-06-01 12:58 GMT+02:00 Thomas Andraschko <andraschko.thomas@gmail.com
>> >:
>>
>> > Hi,
>> >
>> > ~1 year ago i did many optimizations in the data module and AFAIR DS
>> > Data was only a little bit slower.
>> > After i compared my testcase with a benchmark from a user, the big
>> > different came from the transaction handling which was different in
>> > both testcases.
>> >
>> > Regards,
>> > Thomas
>> >
>> > 2017-06-01 12:33 GMT+02:00 Gerhard Petracek <gpetracek@apache.org>:
>> >
>> > > hi johannes,
>> > >
>> > > after refactoring your initial code to ds-test-control i saw e.g.
>> > > ~6s vs 7,5s for 2560 iterations.
>> > > i'll compare my local version with your new version (mentioned in
>> > > your mail).
>> > >
>> > > regards,
>> > > gerhard
>> > >
>> > >
>> > >
>> > > 2017-06-01 11:35 GMT+02:00 Schäfer, Johannes <jschaefer@psi.de>:
>> > >
>> > > > Hi,
>> > > >
>> > > > My company is thinking about using DeltaSpike Data. But before we
>> > > > integrate this into our development I was asked to prepare some
>> > > benchmarks,
>> > > > comparing the usage of DeltaSpike Data with the usage of a plain
>> > > > EntityManager.
>> > > > I prepared some benchmarks and I was surprised that there is a big
>> > > > difference in the write performance. I already got some hints in
>> > > > the
>> > > delta
>> > > > spike irc channel, but the performance is still bad.
>> > > > Based on a template from os890 I implemented my tests and prepared
>> > > > a github project.
>> > > > https://github.com/johannesschaefer/javaee_jsf_
>> > cdi_jpa_data_ds_project_
>> > > > template
>> > > > Basically I'm talking about this test:
>> > > > https://github.com/johannesschaefer/javaee_jsf_
>> > cdi_jpa_data_ds_project_
>> > > > template/blob/master/src/test/java/de/psi/metals/futurelab/
>> > > > repo/benchmark/SaveTest.java
>> > > >
>> > > > It just saves an entity into a DB in a loop. Depending of the
>> > > > number of iterations the difference is quite big.
>> > > >
>> > > > SaveTest
>> > > > ____________________________________________________________
>> > > > ____________________________________________________________
>> > > > _____________________________
>> > > > |   | iter 10    | iter 20    | iter 40    | iter 80    | iter 160
>>  |
>> > > > iter 320   | iter 640   | iter 1280  | iter 2560  | iter 5120   |
>> iter
>> > > > 10240  |
>> > > > |===========================================================
>> > > > ============================================================
>> > > > =============================|
>> > > > | DS| 0.004911746| 0.03597043 | 0.015765787| 0.016966639|
>> > > > | DS| 0.043319612|
>> > > > 0.281807839| 1.308948835| 1.370535533| 8.186996818| 20.920141274|
>> > > > 93.631768475|
>> > > > | EM| 0.004557839| 0.003256631| 0.005775416| 0.004834958|
>> > > > | EM| 0.028243393|
>> > > > 0.035484616| 0.038600595| 0.088904458| 0.339158674| 0.745850523 |
>> > > > 0.853543234 |
>> > > >
>> > > > Also the difference between a run with 5120 and 10240 iteration is
>> > > > not just the double amount of time, it is more than 4 times more.
>> > > >
>> > > > Do you have some hints to me what I'm doing wrong there?
>> > > >
>> > > > Regards
>> > > > Johannes
>> > > >
>> > > >
>> > > >
>> > >
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message