Hi Ilan.
Do not forget to enable statement pooling in database connection pool
configuration, if it is not enabled by default.
Best regards
Georgi
Jeremy Bauer wrote:
Hi Ilan,
Thanks for your post, additional details about JPAB, and your willingness to
try different OpenJPA configurations. While the performance gap is
concerning, myself and others are especially concerned with the functional
problems you are seeing. I downloaded the benchmark jar and was able to
reproduce the errors you've documented. Running the multi-threaded tests
with OpenJPA 2.0.0 on a multi-core system consistently produced duplicate
key exceptions. I found that this issue is fixed in our 2.0.2-SNAPSHOT and
also in 2.1.0-SNAPSHOT/trunk. However, the 2.0.2 snapshot runs into another
threading issue, which is caused by OpenJPA's QuerySQLCache. By disabling
the cache with the property below, I was able to get a clean run with
2.0.2-SNAPSHOT. Current trunk level code has some fixes in this area and
worked without it.
property-3=<property name="openjpa.jdbc.QuerySQLCache" value="false"/>
I am doing a bit of experimentation with the benchmark in the areas of
connection pooling, data caching, and statement batching. While OpenJPA has
many performance tuning switches and dials, these three typically have the
most impact. Some of the other providers have these performance features
enabled by default, so enabling them in OpenJPA helps level the field.
If you have time and wouldn't mind giving OpenJPA another go, you can get
the latest 2.1.0-SNAPSHOT from here:
https://repository.apache.org/snapshots/org/apache/openjpa/apache-openjpa/2.1.0-SNAPSHOT/
as of this note the latest snapshot is
https://repository.apache.org/snapshots/org/apache/openjpa/apache-openjpa/2.1.0-SNAPSHOT/apache-openjpa-2.1.0-20101104.065025-93-binary.zip
This snapshot has connection pooling included and enabled by default. If
you'd like, you can enable basic, un-tuned, statement batching and data
caching with these properties.
property-3=<property name="openjpa.DataCache" value="true"/>
property-4=<property name="openjpa.jdbc.DBDictionary"
value="batchLimit=100"/>
I and I'm sure others others would be interested in the result. If I come
up with a better set of basic tuning parameters, I'll pass them along.
Others, please feel free to do the same.
-Jeremy
On Wed, Nov 3, 2010 at 11:24 AM, Ilan Kirsh <[email protected]> wrote:
Hi all,
I am the author of the http://www.jpab.org JPAB benchmark .
As Rick wrote - this is indeed an out of the box benchmark. Default
configuration was used for all the tested products.
I read with interest what you said about connection pooling. I am keen to
try this but I wonder whether it will really make a difference because the
tests do not use short term database connections, and anyway, the time of
connecting to the database is excluded from the time measurement.
But probably there are other things that can be done to improve
performance.
I'd like to run the tests again with optimized OpenJPA configuration but
for
this I will need some help from OpenJPA experts.
Regarding test failures - I have used standard JPA for the tests. I am
obviously keen to fix up any problems which are my errors, though, so I'd
be
very happy for details I have got incorrect to be pointed out and fixed.
However, please notice that the same tests that failed with OpenJPA passes
with other combinations such as Hibernate/MySQL. Therefore, this could
really be a problem with the OpenJPA processing, as Kevin wrote. I think
that these tests indicate at least some issues that might have to be fixed
in OpenJPA.
Finally, I'd like to address any concerns that the tests are specifically
designed to make http://www.objectdb.com ObjectDB look best. The tests
are
very simple and include only standard JPA operations on simple object
models. It is open source - does anyone see anything that is biased towards
ObjectDB performance? Actually, the performance gap could be even larger
if
the object model would be more complex. It is true, however, as explained
on
http://www.jpab.org/Benchmark_FAQ.html, that when the bottleneck is disk
activity or network overhead - performance gaps are expected to be much
lower.
Best regards,
Ilan Kirsh
--
View this message in context:
http://openjpa.208410.n2.nabble.com/JPAB-results-tp5693298p5702044.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
