Hi everybody,
I did implement the equals and hash-Methods now. I also made sure to
have 1000 different (ID) entries in the database.
It didn't change the performance at all.
I also tried the @Cache(shared=false) annotation. Also without any
difference.
Also mind that it's deprecated already:
http://www.eclipse.org/eclipselink/api/2.2/org/eclipse/persistence/annotations/Cache.html
So I tried the CacheIsolationType.ISOLATED - unfortunately with the same
result.
Richard Kolb wrote:
> Maybe a bit off the topic, but have you tried other options to increase
> performance like @Asynchronous.
> It's really a magic part of Java EE 6.
At the moment I just want to compare the query performance of the
several options
> Maybe changing the Batch Size :
> http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_(ELUG)#Fetch_Size
Setting it to 500 (half) at first seemd to help gain a few tenths but
after several attempts it was clear that it didn't statistically.
> And statement Caching :
> http://wiki.eclipse.org/Optimizing_the_EclipseLink_Application_(ELUG)#How_to_Use_Parameterized_SQL_.28Parameter_Binding.29_and_Prepared_Statement_Caching_for_Optimization
This chewed off some tenths:
* JDBC: 4.6s (4.7 before)
* JPA (nativeQuery): 6.6s (7.2 before)
* EJB: 7.1s (7.5 before)
Another thing came to my mind: the initialize/warmup time of the
container/JPA/whatever. So I added a warmup select run to each of the
tests. This doesn't improve the overall performance, but improves the
test setup and makes it a bit more like in real life.
Also the number of runs isn't static anymore in my test, so the JVMs
optimizer seems to have a hard time with this - as a result all test
durations increased, which is OK for comparisons's sake.
Results are:
* JDBC: 5.1s
* JPA: 7.1s (+2s, +2.5s before optimizations)
* EJB: 7.7s (+2.6s, +2.8s before optimizations)
So JPA (native Query without Entities) seems to have gained more from
the optimizations than the Entity approach.
Still it's a lot worse than pure JDBC.
Is anybody able to reproduce these results? As always, I have attached
my current test project.
> Finally EclipseLink has a profiler.
> Never used it, but sounds promising :
> http://wiki.eclipse.org/Optimizing_the_EclipseLink_Application_(ELUG)#Measuring_EclipseLink_Performance_with_the_EclipseLink_Profiler
Whow, what a cool feature!
I tried it but couldn't take a conclusion from the profiling information
(decreasing iterations from 2000 to 10 per test...) yet.
Cheers,
Matthias