You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by sgjava <sg...@gmail.com> on 2017/06/20 03:06:07 UTC
JPA vs DBUtils
I just built a project to compare JPA+Hibernate to a DBUtils implementation.
DBUtils is a lot faster by a large margin. Can anyone tell me if they have
tuned JPA to perform better? I used TomEE 7.0.4-SNAPSHOT. I could live with
maybe a 10% difference, but I'm talking about 10 to 10 times slower!
https://github.com/sgjava/jpavsdbutils
--
View this message in context: http://tomee-openejb.979440.n4.nabble.com/JPA-vs-DBUtils-tp4681918.html
Sent from the TomEE Users mailing list archive at Nabble.com.
Re: JPA vs DBUtils
Posted by Steve Goldsmith <sg...@gmail.com>.
I've already built scalable distributed applications using TomEE, EJB, MDB,
JCache and DBUtils handling millions of transactions a day that have been
in production for years. I believe if you understand the use case then you
can make the proper architectural decisions. Sometimes JPA is overkill/not
functional especially when dealing with legacy databases that were not
forward engineered with an ORM in mind. You'll often run into Object
Relational Impedance Mismatch or something JPQL simply will not be able to
handle efficiently or effectively. This is something you'll experience in
the field.
I wasn't trying to say DbUtils == JPA, but if the use case permits it may
be more scalable and that's what I'm trying to find out (you do not know
unless you try). I've made some of the suggested changes and ran into a
problem with JPA delete, so I'm working through that now. My goal here
wasn't to trash TomEE or JPA, but rather contrast the performance for some
persistence use cases. If anything it may be an opportunity to update some
of the examples or create new ones. I really appreciate your advice trying
to make the comparison more fair.
PS, using the same data made no difference since it was exactly the same
since and number of entities :) I still changed the test to use the exact
same data and I'm making the other changes as well.
On Tue, Jun 20, 2017 at 6:25 PM, Andy Gumbrecht <ag...@tomitribe.com>
wrote:
> Steve,
>
> The issue here is that the JPA vs DBUtils comparison is not really valid,
> and the example is nothing like a benchmark. TomEE can't be put on the
> hotplate for Hibernate/JPA, which is a huge huge topic with tons and tons
> of documentation. TomEE is 'just' the 'enabler' here. If you are weighing
> up using DBUtils over JPA (Hibernate, EclipseLink, OpenJPA, etc.) for any
> kind of enterprise application then I can assure you that you'd need to dig
> much deeper than this to make a decision, although I would explicitly
> recommend using JPA.
>
> I don't want us to sound autoritative to you as we're only trying to help
> you (in our free time), but the 'under the hood' information that you are
> missing on JPA and EE to enable a proper discussion would require some
> reading time on your part. Basically JPA can be scaled over a huge scope on
> many nodes with interoperability to many technologies out of the box, and
> DBUtils is a very very simple layer over JDBC and nothing more.
>
> What you are asking for is to make your JPA example match the performance
> of your DBUtils example. The random data may be the same size, but that was
> not the only suggestion I made, and is simply a golden rule for starting a
> data benchmark - Use the same data. Please try the other suggestions which
> will have a direct impact on performance, but is still just a scratch on
> the options available.
>
> Andy.
>
> On 20 June 2017 at 16:21, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > not really, @Stateful vs @Stateful + extended persistence context. This
> is
> > quite particular more particular. However overhead is really in the way
> jpa
> > does way more for you, compare your updates for instance.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-06-20 16:16 GMT+02:00 Steve Goldsmith <sg...@gmail.com>:
> >
> > > @Stateful was used in both examples, so the impact would have been the
> > > same? The real way to find the latency is to profile the code which I
> > will
> > > do as well.
> > >
> > > On Tue, Jun 20, 2017 at 10:03 AM, Romain Manni-Bucau <
> > > rmannibucau@gmail.com>
> > > wrote:
> > >
> > > > not sure what you reference by "string" but JPA needs more round trip
> > to
> > > be
> > > > "hot" (optimized) than dbutils which doesnt pretty much nothing. The
> > > state
> > > > management etc is also an overhead.
> > > >
> > > > If you update your example to have a @Version for instance you will
> > start
> > > > to realize it, then add a small layer to not have to build yourself
> the
> > > > update query and you will see another part etc.
> > > >
> > > > I would probably recommand you to maybe evaluate this: try with mysql
> > to
> > > > have some real db latency and compare the db latency to jpa overhead
> -
> > > > and/or try with N threads with hsqldb ;).
> > > >
> > > > Generally the overhead once tuned is acceptable compared to the DB
> > > latency
> > > > and you are often in the IO layer and not the runtime layer.
> > > >
> > > > Side note about the example: i think the goal was to show how to use
> a
> > > > stateful, name is probably not that great :s
> > > >
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > > rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > >
> > > > 2017-06-20 15:58 GMT+02:00 Steve Goldsmith <sg...@gmail.com>:
> > > >
> > > > > I copied the JPA stuff from the TomEE examples, so if it is not
> > > > optimized,
> > > > > using the wrong state, scope, etc. then perhaps the example should
> be
> > > > > updated to reflect that. I will try what you recommend and post new
> > > > times.
> > > > > The data is exactly the same size, so are you saying because the
> > > strings
> > > > > are not identical there may be a difference? Just trying to
> > understand
> > > > that
> > > > > perspective. I'll just roll both tests into one to use the same
> data.
> > > > >
> > > > > On Tue, Jun 20, 2017 at 2:53 AM, Andy Gumbrecht <
> > > > agumbrecht@tomitribe.com>
> > > > > wrote:
> > > > >
> > > > > > So just at a super quick glance - Before we start to anything
> else.
> > > > > >
> > > > > > You should modify the code to use the same (identical) random
> data
> > > for
> > > > > both
> > > > > > tests.
> > > > > > Add hibernate.jdbc.batch_size = 25 to your persistence.xml
> > properties
> > > > > > Never use @Stateful unless you really understand why you should,
> > i.e.
> > > > use
> > > > > > @Stateless for your JpaMovies
> > > > > > Use entityManager#find rather than a query
> > > > > >
> > > > > > Hope this is a quick insight, but I'd also be interested to see
> the
> > > > > results
> > > > > > on just these few changes.
> > > > > >
> > > > > > Andy.
> > > > > >
> > > > > > On 20 June 2017 at 05:31, Laird Nelson <lj...@gmail.com>
> wrote:
> > > > > >
> > > > > > > Have you sat down for a good long reading session with
> > > > > > > http://java-persistence-performance.blogspot.com/? I found
> that
> > > > site
> > > > > > > invaluable.
> > > > > > >
> > > > > > > Best,
> > > > > > > Laird
> > > > > > > --
> > > > > > > http://about.me/lairdnelson
> > > > > > >
> > > > > > > On Mon, Jun 19, 2017 at 8:22 PM sgjava <sg...@gmail.com>
> wrote:
> > > > > > >
> > > > > > > > I just built a project to compare JPA+Hibernate to a DBUtils
> > > > > > > > implementation.
> > > > > > > > DBUtils is a lot faster by a large margin. Can anyone tell me
> > if
> > > > they
> > > > > > > have
> > > > > > > > tuned JPA to perform better? I used TomEE 7.0.4-SNAPSHOT. I
> > could
> > > > > live
> > > > > > > with
> > > > > > > > maybe a 10% difference, but I'm talking about 10 to 10 times
> > > > slower!
> > > > > > > >
> > > > > > > > https://github.com/sgjava/jpavsdbutils
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > View this message in context:
> > > > > > > > http://tomee-openejb.979440.n4.nabble.com/JPA-vs-DBUtils-
> > > > > > tp4681918.html
> > > > > > > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Andy Gumbrecht
> > > > > > https://twitter.com/AndyGeeDe
> > > > > > http://www.tomitribe.com
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Steven P. Goldsmith
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Steven P. Goldsmith
> > >
> >
>
>
>
> --
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
>
--
Steven P. Goldsmith
Re: JPA vs DBUtils
Posted by sgjava <sg...@gmail.com>.
No worries, I just wanted you to know I have quite of bit of Java EE
experience and wasn't trying to be one of those annoying noobs trying to
waste your time :) I know this isn't a scientific performance test, but it's
something to start a discussion (which it did). After adding the latest
suggestions things are getting closer:
Jun 21, 2017 11:44:22 AM com.codeferm.jpavsdbutils.PerformanceTest
performance
INFO: JPA add elapsed milliseconds: 1111
Jun 21, 2017 11:44:22 AM com.codeferm.jpavsdbutils.PerformanceTest
performance
INFO: JPA get elapsed milliseconds: 55
Jun 21, 2017 11:44:23 AM com.codeferm.jpavsdbutils.PerformanceTest
performance
INFO: JPA delete elapsed milliseconds: 641
Jun 21, 2017 11:44:23 AM com.codeferm.jpavsdbutils.PerformanceTest
performance
INFO: DbUtils add elapsed milliseconds: 375
Jun 21, 2017 11:44:23 AM com.codeferm.jpavsdbutils.PerformanceTest
performance
INFO: DbUtils get elapsed milliseconds: 40
Jun 21, 2017 11:44:23 AM com.codeferm.jpavsdbutils.PerformanceTest
performance
INFO: DbUtils delete elapsed milliseconds: 306
I ran the tests twice in the same container to factor in JIT improvements. I
also added the OpenEJB javaagent since it was complaining about not
optimizing the JPA entity class. Things are much closer now. Latest is on
Github https://github.com/sgjava/jpavsdbutils
--
View this message in context: http://tomee-openejb.979440.n4.nabble.com/JPA-vs-DBUtils-tp4681918p4681939.html
Sent from the TomEE Users mailing list archive at Nabble.com.
Re: JPA vs DBUtils
Posted by Andy Gumbrecht <ag...@tomitribe.com>.
Steve, wasn't trying to negate your experience, so sorry if that came
across that way.
As you have already built scaleable apps with DBUtils then you really
understand the extra overhead and legwork that was involved in doing that
and getting it right.
I was just trying to make the point that JPA and EE simply provides much of
that legwork for you out of the box, but it does require a deeper
understanding than presented by the initial example. The awesome tests
provided by Romain really highlight that point.
The 'data' aspect was not a candidate for improving the performance, but
nice to see that you have now toyed with the other suggestions and can see
some significant improvements.
Improving the examples is always a good idea and we're always really happy
to take patches.
There is never a golden rule and there are literally hundreds of portable
(and some not so portable) tweaks that can be made for the various JPA
providers, but glad you're more on track now.
The edge cases are still valid, and can also be solved by injecting the
DataSource and using DBUtils or even JDBC directly when required, but I'd
still try JPA native queries first.
Andy.
On 21 June 2017 at 15:21, Romain Manni-Bucau <rm...@gmail.com> wrote:
> [disclaimer]before next statement is really accurate ensure the app / db
> latency doesn't make it negligible[/]
>
> If you use hibernate, the stateless mode can help. Using just the mapping
> part of JPA - without entities - for queries can as well.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-06-21 15:11 GMT+02:00 Steve Goldsmith <sg...@gmail.com>:
>
> > Thanks, I will incorporate those changes. My real goal is to use JPA for
> > speed critical applications, so the runtime potion is important as the
> > database latency will be the same assuming the generated SQL is the same.
> > This definitely gets me on the right track.
> >
> > On Wed, Jun 21, 2017 at 2:32 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >
> > wrote:
> >
> > > here what i get using TRANSACTION and openjpa (hibernate should follow
> > the
> > > same curve) -
> > > https://gist.github.com/rmannibucau/7b49bdfc5c83c59f065d50764603c265:
> > >
> > >
> > > juin 21, 2017 8:00:15 AM com.codeferm.jpavsdbutils.JpaTest run
> > > INFOS: Add elapsed milliseconds: 362
> > > juin 21, 2017 8:00:15 AM com.codeferm.jpavsdbutils.JpaTest run
> > > INFOS: Get elapsed milliseconds: 75
> > > juin 21, 2017 8:00:16 AM com.codeferm.jpavsdbutils.JpaTest run
> > > INFOS: Delete elapsed milliseconds: 438
> > >
> > >
> > >
> > > juin 21, 2017 7:55:24 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> > > INFOS: Add elapsed milliseconds: 223
> > > juin 21, 2017 7:55:24 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> > > INFOS: Get elapsed milliseconds: 14
> > > juin 21, 2017 7:55:24 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> > > INFOS: Delete elapsed milliseconds: 185
> > >
> > >
> > > If you *enhance* the entities before running the test:
> > >
> > > juin 21, 2017 8:13:10 AM com.codeferm.jpavsdbutils.JpaTest run
> > > INFOS: Add elapsed milliseconds: 356
> > > juin 21, 2017 8:13:10 AM com.codeferm.jpavsdbutils.JpaTest run
> > > INFOS: Get elapsed milliseconds: 19
> > > juin 21, 2017 8:13:10 AM com.codeferm.jpavsdbutils.JpaTest run
> > > INFOS: Delete elapsed milliseconds: 332
> > >
> > > juin 21, 2017 8:13:15 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> > > INFOS: Add elapsed milliseconds: 182
> > > juin 21, 2017 8:13:15 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> > > INFOS: Get elapsed milliseconds: 10
> > > juin 21, 2017 8:13:15 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> > > INFOS: Delete elapsed milliseconds: 169
> > >
> > > For a monothreaded, embedded database test it is not that bad since JPA
> > > does the mapping you don't request to dbutils.
> > >
> > > Side note: you should also ensure dbutils and jpa tests dont share the
> > same
> > > JVM otherwsie one uses a more "hot" jvm than the other (forkMode=always
> > for
> > > example).
> > >
> > > One thing which is different is JPA has a built-in cache (the
> > entitymanager
> > > itself, "1st level cache"), this cache is a "map" and its capacity is
> 16,
> > > if you dont use 100000 items but 16 both cases will result in 0ms. If
> you
> > > use nano you get - added spaces to make it readable:
> > >
> > > juin 21, 2017 8:23:48 AM com.codeferm.jpavsdbutils.JpaTest run
> > > INFOS: Add elapsed milliseconds: 542 549
> > > juin 21, 2017 8:23:48 AM com.codeferm.jpavsdbutils.JpaTest run
> > > INFOS: Get elapsed milliseconds: 231 753
> > > juin 21, 2017 8:23:48 AM com.codeferm.jpavsdbutils.JpaTest run
> > > INFOS: Delete elapsed milliseconds: 1 005 269
> > >
> > > juin 21, 2017 8:23:50 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> > > INFOS: Add elapsed milliseconds: 326 396
> > > juin 21, 2017 8:23:50 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> > > INFOS: Get elapsed milliseconds: 85 400
> > > juin 21, 2017 8:23:50 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> > > INFOS: Delete elapsed milliseconds: 308 996
> > >
> > > And if you move to RESOURCE_LOCAL avoiding the JTA datasource +
> > transaction
> > > manager overhead:
> > >
> > > juin 21, 2017 8:30:13 AM com.codeferm.jpavsdbutils.JpaTest run
> > > INFOS: Add elapsed milliseconds: 337 039
> > > juin 21, 2017 8:30:13 AM com.codeferm.jpavsdbutils.JpaTest run
> > > INFOS: Get elapsed milliseconds: 139 670
> > > juin 21, 2017 8:30:13 AM com.codeferm.jpavsdbutils.JpaTest run
> > > INFOS: Delete elapsed milliseconds: 381 337
> > >
> > > Yes, you can't blame JPA ;)
> > >
> > > Now if you compare it to real life database latency it should stay
> small
> > to
> > > not affect much the application but if you are still motivated to get
> > this
> > > boost deltaspike will make it smooth.
> > >
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > >
> > > 2017-06-21 3:58 GMT+02:00 sgjava <sg...@gmail.com>:
> > >
> > > > OK, using here's the changes I made and the performance is much
> better
> > > now
> > > > (using same data set) for JPA:
> > > >
> > > > `<property name="hibernate.jdbc.batch_size" value="25"/> ` no
> > difference
> > > > PersistenceContextType.TRANSACTION
> > > > @Singleton
> > > >
> > > > DBUtils bean is still using @Stateful since I do not want to create
> > > > QueryRunner, ScalarHandler and BeanListHandler on each invocation.
> Any
> > > > other
> > > > JPA optimization I should make to make it more comparable to DBUtils?
> > > >
> > > > Jun 20, 2017 9:39:40 PM com.codeferm.jpavsdbutils.PerformanceTest
> > > > performance
> > > > INFO: JPA add elapsed milliseconds: 4765
> > > > Jun 20, 2017 9:39:40 PM com.codeferm.jpavsdbutils.PerformanceTest
> > > > performance
> > > > INFO: JPA get elapsed milliseconds: 323
> > > > Jun 20, 2017 9:39:45 PM com.codeferm.jpavsdbutils.PerformanceTest
> > > > performance
> > > > INFO: JPA delete elapsed milliseconds: 5035
> > > >
> > > > Jun 20, 2017 9:39:47 PM com.codeferm.jpavsdbutils.PerformanceTest
> > > > performance
> > > > INFO: DbUtils add elapsed milliseconds: 1757
> > > > Jun 20, 2017 9:39:47 PM com.codeferm.jpavsdbutils.PerformanceTest
> > > > performance
> > > > INFO: DbUtils get elapsed milliseconds: 67
> > > > Jun 20, 2017 9:39:48 PM com.codeferm.jpavsdbutils.PerformanceTest
> > > > performance
> > > > INFO: DbUtils delete elapsed milliseconds: 895
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > View this message in context: http://tomee-openejb.979440.
> > > > n4.nabble.com/JPA-vs-DBUtils-tp4681918p4681932.html
> > > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > > >
> > >
> >
> >
> >
> > --
> > Steven P. Goldsmith
> >
>
--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
Re: JPA vs DBUtils
Posted by Romain Manni-Bucau <rm...@gmail.com>.
[disclaimer]before next statement is really accurate ensure the app / db
latency doesn't make it negligible[/]
If you use hibernate, the stateless mode can help. Using just the mapping
part of JPA - without entities - for queries can as well.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2017-06-21 15:11 GMT+02:00 Steve Goldsmith <sg...@gmail.com>:
> Thanks, I will incorporate those changes. My real goal is to use JPA for
> speed critical applications, so the runtime potion is important as the
> database latency will be the same assuming the generated SQL is the same.
> This definitely gets me on the right track.
>
> On Wed, Jun 21, 2017 at 2:32 AM, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> wrote:
>
> > here what i get using TRANSACTION and openjpa (hibernate should follow
> the
> > same curve) -
> > https://gist.github.com/rmannibucau/7b49bdfc5c83c59f065d50764603c265:
> >
> >
> > juin 21, 2017 8:00:15 AM com.codeferm.jpavsdbutils.JpaTest run
> > INFOS: Add elapsed milliseconds: 362
> > juin 21, 2017 8:00:15 AM com.codeferm.jpavsdbutils.JpaTest run
> > INFOS: Get elapsed milliseconds: 75
> > juin 21, 2017 8:00:16 AM com.codeferm.jpavsdbutils.JpaTest run
> > INFOS: Delete elapsed milliseconds: 438
> >
> >
> >
> > juin 21, 2017 7:55:24 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> > INFOS: Add elapsed milliseconds: 223
> > juin 21, 2017 7:55:24 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> > INFOS: Get elapsed milliseconds: 14
> > juin 21, 2017 7:55:24 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> > INFOS: Delete elapsed milliseconds: 185
> >
> >
> > If you *enhance* the entities before running the test:
> >
> > juin 21, 2017 8:13:10 AM com.codeferm.jpavsdbutils.JpaTest run
> > INFOS: Add elapsed milliseconds: 356
> > juin 21, 2017 8:13:10 AM com.codeferm.jpavsdbutils.JpaTest run
> > INFOS: Get elapsed milliseconds: 19
> > juin 21, 2017 8:13:10 AM com.codeferm.jpavsdbutils.JpaTest run
> > INFOS: Delete elapsed milliseconds: 332
> >
> > juin 21, 2017 8:13:15 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> > INFOS: Add elapsed milliseconds: 182
> > juin 21, 2017 8:13:15 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> > INFOS: Get elapsed milliseconds: 10
> > juin 21, 2017 8:13:15 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> > INFOS: Delete elapsed milliseconds: 169
> >
> > For a monothreaded, embedded database test it is not that bad since JPA
> > does the mapping you don't request to dbutils.
> >
> > Side note: you should also ensure dbutils and jpa tests dont share the
> same
> > JVM otherwsie one uses a more "hot" jvm than the other (forkMode=always
> for
> > example).
> >
> > One thing which is different is JPA has a built-in cache (the
> entitymanager
> > itself, "1st level cache"), this cache is a "map" and its capacity is 16,
> > if you dont use 100000 items but 16 both cases will result in 0ms. If you
> > use nano you get - added spaces to make it readable:
> >
> > juin 21, 2017 8:23:48 AM com.codeferm.jpavsdbutils.JpaTest run
> > INFOS: Add elapsed milliseconds: 542 549
> > juin 21, 2017 8:23:48 AM com.codeferm.jpavsdbutils.JpaTest run
> > INFOS: Get elapsed milliseconds: 231 753
> > juin 21, 2017 8:23:48 AM com.codeferm.jpavsdbutils.JpaTest run
> > INFOS: Delete elapsed milliseconds: 1 005 269
> >
> > juin 21, 2017 8:23:50 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> > INFOS: Add elapsed milliseconds: 326 396
> > juin 21, 2017 8:23:50 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> > INFOS: Get elapsed milliseconds: 85 400
> > juin 21, 2017 8:23:50 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> > INFOS: Delete elapsed milliseconds: 308 996
> >
> > And if you move to RESOURCE_LOCAL avoiding the JTA datasource +
> transaction
> > manager overhead:
> >
> > juin 21, 2017 8:30:13 AM com.codeferm.jpavsdbutils.JpaTest run
> > INFOS: Add elapsed milliseconds: 337 039
> > juin 21, 2017 8:30:13 AM com.codeferm.jpavsdbutils.JpaTest run
> > INFOS: Get elapsed milliseconds: 139 670
> > juin 21, 2017 8:30:13 AM com.codeferm.jpavsdbutils.JpaTest run
> > INFOS: Delete elapsed milliseconds: 381 337
> >
> > Yes, you can't blame JPA ;)
> >
> > Now if you compare it to real life database latency it should stay small
> to
> > not affect much the application but if you are still motivated to get
> this
> > boost deltaspike will make it smooth.
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-06-21 3:58 GMT+02:00 sgjava <sg...@gmail.com>:
> >
> > > OK, using here's the changes I made and the performance is much better
> > now
> > > (using same data set) for JPA:
> > >
> > > `<property name="hibernate.jdbc.batch_size" value="25"/> ` no
> difference
> > > PersistenceContextType.TRANSACTION
> > > @Singleton
> > >
> > > DBUtils bean is still using @Stateful since I do not want to create
> > > QueryRunner, ScalarHandler and BeanListHandler on each invocation. Any
> > > other
> > > JPA optimization I should make to make it more comparable to DBUtils?
> > >
> > > Jun 20, 2017 9:39:40 PM com.codeferm.jpavsdbutils.PerformanceTest
> > > performance
> > > INFO: JPA add elapsed milliseconds: 4765
> > > Jun 20, 2017 9:39:40 PM com.codeferm.jpavsdbutils.PerformanceTest
> > > performance
> > > INFO: JPA get elapsed milliseconds: 323
> > > Jun 20, 2017 9:39:45 PM com.codeferm.jpavsdbutils.PerformanceTest
> > > performance
> > > INFO: JPA delete elapsed milliseconds: 5035
> > >
> > > Jun 20, 2017 9:39:47 PM com.codeferm.jpavsdbutils.PerformanceTest
> > > performance
> > > INFO: DbUtils add elapsed milliseconds: 1757
> > > Jun 20, 2017 9:39:47 PM com.codeferm.jpavsdbutils.PerformanceTest
> > > performance
> > > INFO: DbUtils get elapsed milliseconds: 67
> > > Jun 20, 2017 9:39:48 PM com.codeferm.jpavsdbutils.PerformanceTest
> > > performance
> > > INFO: DbUtils delete elapsed milliseconds: 895
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context: http://tomee-openejb.979440.
> > > n4.nabble.com/JPA-vs-DBUtils-tp4681918p4681932.html
> > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > >
> >
>
>
>
> --
> Steven P. Goldsmith
>
Re: JPA vs DBUtils
Posted by Steve Goldsmith <sg...@gmail.com>.
Thanks, I will incorporate those changes. My real goal is to use JPA for
speed critical applications, so the runtime potion is important as the
database latency will be the same assuming the generated SQL is the same.
This definitely gets me on the right track.
On Wed, Jun 21, 2017 at 2:32 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> here what i get using TRANSACTION and openjpa (hibernate should follow the
> same curve) -
> https://gist.github.com/rmannibucau/7b49bdfc5c83c59f065d50764603c265:
>
>
> juin 21, 2017 8:00:15 AM com.codeferm.jpavsdbutils.JpaTest run
> INFOS: Add elapsed milliseconds: 362
> juin 21, 2017 8:00:15 AM com.codeferm.jpavsdbutils.JpaTest run
> INFOS: Get elapsed milliseconds: 75
> juin 21, 2017 8:00:16 AM com.codeferm.jpavsdbutils.JpaTest run
> INFOS: Delete elapsed milliseconds: 438
>
>
>
> juin 21, 2017 7:55:24 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> INFOS: Add elapsed milliseconds: 223
> juin 21, 2017 7:55:24 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> INFOS: Get elapsed milliseconds: 14
> juin 21, 2017 7:55:24 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> INFOS: Delete elapsed milliseconds: 185
>
>
> If you *enhance* the entities before running the test:
>
> juin 21, 2017 8:13:10 AM com.codeferm.jpavsdbutils.JpaTest run
> INFOS: Add elapsed milliseconds: 356
> juin 21, 2017 8:13:10 AM com.codeferm.jpavsdbutils.JpaTest run
> INFOS: Get elapsed milliseconds: 19
> juin 21, 2017 8:13:10 AM com.codeferm.jpavsdbutils.JpaTest run
> INFOS: Delete elapsed milliseconds: 332
>
> juin 21, 2017 8:13:15 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> INFOS: Add elapsed milliseconds: 182
> juin 21, 2017 8:13:15 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> INFOS: Get elapsed milliseconds: 10
> juin 21, 2017 8:13:15 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> INFOS: Delete elapsed milliseconds: 169
>
> For a monothreaded, embedded database test it is not that bad since JPA
> does the mapping you don't request to dbutils.
>
> Side note: you should also ensure dbutils and jpa tests dont share the same
> JVM otherwsie one uses a more "hot" jvm than the other (forkMode=always for
> example).
>
> One thing which is different is JPA has a built-in cache (the entitymanager
> itself, "1st level cache"), this cache is a "map" and its capacity is 16,
> if you dont use 100000 items but 16 both cases will result in 0ms. If you
> use nano you get - added spaces to make it readable:
>
> juin 21, 2017 8:23:48 AM com.codeferm.jpavsdbutils.JpaTest run
> INFOS: Add elapsed milliseconds: 542 549
> juin 21, 2017 8:23:48 AM com.codeferm.jpavsdbutils.JpaTest run
> INFOS: Get elapsed milliseconds: 231 753
> juin 21, 2017 8:23:48 AM com.codeferm.jpavsdbutils.JpaTest run
> INFOS: Delete elapsed milliseconds: 1 005 269
>
> juin 21, 2017 8:23:50 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> INFOS: Add elapsed milliseconds: 326 396
> juin 21, 2017 8:23:50 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> INFOS: Get elapsed milliseconds: 85 400
> juin 21, 2017 8:23:50 AM com.codeferm.jpavsdbutils.DbUtilsTest run
> INFOS: Delete elapsed milliseconds: 308 996
>
> And if you move to RESOURCE_LOCAL avoiding the JTA datasource + transaction
> manager overhead:
>
> juin 21, 2017 8:30:13 AM com.codeferm.jpavsdbutils.JpaTest run
> INFOS: Add elapsed milliseconds: 337 039
> juin 21, 2017 8:30:13 AM com.codeferm.jpavsdbutils.JpaTest run
> INFOS: Get elapsed milliseconds: 139 670
> juin 21, 2017 8:30:13 AM com.codeferm.jpavsdbutils.JpaTest run
> INFOS: Delete elapsed milliseconds: 381 337
>
> Yes, you can't blame JPA ;)
>
> Now if you compare it to real life database latency it should stay small to
> not affect much the application but if you are still motivated to get this
> boost deltaspike will make it smooth.
>
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-06-21 3:58 GMT+02:00 sgjava <sg...@gmail.com>:
>
> > OK, using here's the changes I made and the performance is much better
> now
> > (using same data set) for JPA:
> >
> > `<property name="hibernate.jdbc.batch_size" value="25"/> ` no difference
> > PersistenceContextType.TRANSACTION
> > @Singleton
> >
> > DBUtils bean is still using @Stateful since I do not want to create
> > QueryRunner, ScalarHandler and BeanListHandler on each invocation. Any
> > other
> > JPA optimization I should make to make it more comparable to DBUtils?
> >
> > Jun 20, 2017 9:39:40 PM com.codeferm.jpavsdbutils.PerformanceTest
> > performance
> > INFO: JPA add elapsed milliseconds: 4765
> > Jun 20, 2017 9:39:40 PM com.codeferm.jpavsdbutils.PerformanceTest
> > performance
> > INFO: JPA get elapsed milliseconds: 323
> > Jun 20, 2017 9:39:45 PM com.codeferm.jpavsdbutils.PerformanceTest
> > performance
> > INFO: JPA delete elapsed milliseconds: 5035
> >
> > Jun 20, 2017 9:39:47 PM com.codeferm.jpavsdbutils.PerformanceTest
> > performance
> > INFO: DbUtils add elapsed milliseconds: 1757
> > Jun 20, 2017 9:39:47 PM com.codeferm.jpavsdbutils.PerformanceTest
> > performance
> > INFO: DbUtils get elapsed milliseconds: 67
> > Jun 20, 2017 9:39:48 PM com.codeferm.jpavsdbutils.PerformanceTest
> > performance
> > INFO: DbUtils delete elapsed milliseconds: 895
> >
> >
> >
> >
> > --
> > View this message in context: http://tomee-openejb.979440.
> > n4.nabble.com/JPA-vs-DBUtils-tp4681918p4681932.html
> > Sent from the TomEE Users mailing list archive at Nabble.com.
> >
>
--
Steven P. Goldsmith
Re: JPA vs DBUtils
Posted by hwaastad <he...@waastad.org>.
Nice analysis, all of you.
My 2 cents is as follows:
1. If caring about performance on queries, use raw.
2. Evaluate if L2 is needed
3. Code maintainability
I think the most important thing to do is to evaluate the resulting sql
while benchmarking your own app. JPA will not always produce the most
effecient sql when it comes to N+1....or when it comes to handle large
collections and lazyness...
/hw
--
View this message in context: http://tomee-openejb.979440.n4.nabble.com/JPA-vs-DBUtils-tp4681918p4681934.html
Sent from the TomEE Users mailing list archive at Nabble.com.
Re: JPA vs DBUtils
Posted by Romain Manni-Bucau <rm...@gmail.com>.
here what i get using TRANSACTION and openjpa (hibernate should follow the
same curve) -
https://gist.github.com/rmannibucau/7b49bdfc5c83c59f065d50764603c265:
juin 21, 2017 8:00:15 AM com.codeferm.jpavsdbutils.JpaTest run
INFOS: Add elapsed milliseconds: 362
juin 21, 2017 8:00:15 AM com.codeferm.jpavsdbutils.JpaTest run
INFOS: Get elapsed milliseconds: 75
juin 21, 2017 8:00:16 AM com.codeferm.jpavsdbutils.JpaTest run
INFOS: Delete elapsed milliseconds: 438
juin 21, 2017 7:55:24 AM com.codeferm.jpavsdbutils.DbUtilsTest run
INFOS: Add elapsed milliseconds: 223
juin 21, 2017 7:55:24 AM com.codeferm.jpavsdbutils.DbUtilsTest run
INFOS: Get elapsed milliseconds: 14
juin 21, 2017 7:55:24 AM com.codeferm.jpavsdbutils.DbUtilsTest run
INFOS: Delete elapsed milliseconds: 185
If you *enhance* the entities before running the test:
juin 21, 2017 8:13:10 AM com.codeferm.jpavsdbutils.JpaTest run
INFOS: Add elapsed milliseconds: 356
juin 21, 2017 8:13:10 AM com.codeferm.jpavsdbutils.JpaTest run
INFOS: Get elapsed milliseconds: 19
juin 21, 2017 8:13:10 AM com.codeferm.jpavsdbutils.JpaTest run
INFOS: Delete elapsed milliseconds: 332
juin 21, 2017 8:13:15 AM com.codeferm.jpavsdbutils.DbUtilsTest run
INFOS: Add elapsed milliseconds: 182
juin 21, 2017 8:13:15 AM com.codeferm.jpavsdbutils.DbUtilsTest run
INFOS: Get elapsed milliseconds: 10
juin 21, 2017 8:13:15 AM com.codeferm.jpavsdbutils.DbUtilsTest run
INFOS: Delete elapsed milliseconds: 169
For a monothreaded, embedded database test it is not that bad since JPA
does the mapping you don't request to dbutils.
Side note: you should also ensure dbutils and jpa tests dont share the same
JVM otherwsie one uses a more "hot" jvm than the other (forkMode=always for
example).
One thing which is different is JPA has a built-in cache (the entitymanager
itself, "1st level cache"), this cache is a "map" and its capacity is 16,
if you dont use 100000 items but 16 both cases will result in 0ms. If you
use nano you get - added spaces to make it readable:
juin 21, 2017 8:23:48 AM com.codeferm.jpavsdbutils.JpaTest run
INFOS: Add elapsed milliseconds: 542 549
juin 21, 2017 8:23:48 AM com.codeferm.jpavsdbutils.JpaTest run
INFOS: Get elapsed milliseconds: 231 753
juin 21, 2017 8:23:48 AM com.codeferm.jpavsdbutils.JpaTest run
INFOS: Delete elapsed milliseconds: 1 005 269
juin 21, 2017 8:23:50 AM com.codeferm.jpavsdbutils.DbUtilsTest run
INFOS: Add elapsed milliseconds: 326 396
juin 21, 2017 8:23:50 AM com.codeferm.jpavsdbutils.DbUtilsTest run
INFOS: Get elapsed milliseconds: 85 400
juin 21, 2017 8:23:50 AM com.codeferm.jpavsdbutils.DbUtilsTest run
INFOS: Delete elapsed milliseconds: 308 996
And if you move to RESOURCE_LOCAL avoiding the JTA datasource + transaction
manager overhead:
juin 21, 2017 8:30:13 AM com.codeferm.jpavsdbutils.JpaTest run
INFOS: Add elapsed milliseconds: 337 039
juin 21, 2017 8:30:13 AM com.codeferm.jpavsdbutils.JpaTest run
INFOS: Get elapsed milliseconds: 139 670
juin 21, 2017 8:30:13 AM com.codeferm.jpavsdbutils.JpaTest run
INFOS: Delete elapsed milliseconds: 381 337
Yes, you can't blame JPA ;)
Now if you compare it to real life database latency it should stay small to
not affect much the application but if you are still motivated to get this
boost deltaspike will make it smooth.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2017-06-21 3:58 GMT+02:00 sgjava <sg...@gmail.com>:
> OK, using here's the changes I made and the performance is much better now
> (using same data set) for JPA:
>
> `<property name="hibernate.jdbc.batch_size" value="25"/> ` no difference
> PersistenceContextType.TRANSACTION
> @Singleton
>
> DBUtils bean is still using @Stateful since I do not want to create
> QueryRunner, ScalarHandler and BeanListHandler on each invocation. Any
> other
> JPA optimization I should make to make it more comparable to DBUtils?
>
> Jun 20, 2017 9:39:40 PM com.codeferm.jpavsdbutils.PerformanceTest
> performance
> INFO: JPA add elapsed milliseconds: 4765
> Jun 20, 2017 9:39:40 PM com.codeferm.jpavsdbutils.PerformanceTest
> performance
> INFO: JPA get elapsed milliseconds: 323
> Jun 20, 2017 9:39:45 PM com.codeferm.jpavsdbutils.PerformanceTest
> performance
> INFO: JPA delete elapsed milliseconds: 5035
>
> Jun 20, 2017 9:39:47 PM com.codeferm.jpavsdbutils.PerformanceTest
> performance
> INFO: DbUtils add elapsed milliseconds: 1757
> Jun 20, 2017 9:39:47 PM com.codeferm.jpavsdbutils.PerformanceTest
> performance
> INFO: DbUtils get elapsed milliseconds: 67
> Jun 20, 2017 9:39:48 PM com.codeferm.jpavsdbutils.PerformanceTest
> performance
> INFO: DbUtils delete elapsed milliseconds: 895
>
>
>
>
> --
> View this message in context: http://tomee-openejb.979440.
> n4.nabble.com/JPA-vs-DBUtils-tp4681918p4681932.html
> Sent from the TomEE Users mailing list archive at Nabble.com.
>
Re: JPA vs DBUtils
Posted by sgjava <sg...@gmail.com>.
OK, using here's the changes I made and the performance is much better now
(using same data set) for JPA:
`<property name="hibernate.jdbc.batch_size" value="25"/> ` no difference
PersistenceContextType.TRANSACTION
@Singleton
DBUtils bean is still using @Stateful since I do not want to create
QueryRunner, ScalarHandler and BeanListHandler on each invocation. Any other
JPA optimization I should make to make it more comparable to DBUtils?
Jun 20, 2017 9:39:40 PM com.codeferm.jpavsdbutils.PerformanceTest
performance
INFO: JPA add elapsed milliseconds: 4765
Jun 20, 2017 9:39:40 PM com.codeferm.jpavsdbutils.PerformanceTest
performance
INFO: JPA get elapsed milliseconds: 323
Jun 20, 2017 9:39:45 PM com.codeferm.jpavsdbutils.PerformanceTest
performance
INFO: JPA delete elapsed milliseconds: 5035
Jun 20, 2017 9:39:47 PM com.codeferm.jpavsdbutils.PerformanceTest
performance
INFO: DbUtils add elapsed milliseconds: 1757
Jun 20, 2017 9:39:47 PM com.codeferm.jpavsdbutils.PerformanceTest
performance
INFO: DbUtils get elapsed milliseconds: 67
Jun 20, 2017 9:39:48 PM com.codeferm.jpavsdbutils.PerformanceTest
performance
INFO: DbUtils delete elapsed milliseconds: 895
--
View this message in context: http://tomee-openejb.979440.n4.nabble.com/JPA-vs-DBUtils-tp4681918p4681932.html
Sent from the TomEE Users mailing list archive at Nabble.com.
Re: JPA vs DBUtils
Posted by Andy Gumbrecht <ag...@tomitribe.com>.
Steve,
The issue here is that the JPA vs DBUtils comparison is not really valid,
and the example is nothing like a benchmark. TomEE can't be put on the
hotplate for Hibernate/JPA, which is a huge huge topic with tons and tons
of documentation. TomEE is 'just' the 'enabler' here. If you are weighing
up using DBUtils over JPA (Hibernate, EclipseLink, OpenJPA, etc.) for any
kind of enterprise application then I can assure you that you'd need to dig
much deeper than this to make a decision, although I would explicitly
recommend using JPA.
I don't want us to sound autoritative to you as we're only trying to help
you (in our free time), but the 'under the hood' information that you are
missing on JPA and EE to enable a proper discussion would require some
reading time on your part. Basically JPA can be scaled over a huge scope on
many nodes with interoperability to many technologies out of the box, and
DBUtils is a very very simple layer over JDBC and nothing more.
What you are asking for is to make your JPA example match the performance
of your DBUtils example. The random data may be the same size, but that was
not the only suggestion I made, and is simply a golden rule for starting a
data benchmark - Use the same data. Please try the other suggestions which
will have a direct impact on performance, but is still just a scratch on
the options available.
Andy.
On 20 June 2017 at 16:21, Romain Manni-Bucau <rm...@gmail.com> wrote:
> not really, @Stateful vs @Stateful + extended persistence context. This is
> quite particular more particular. However overhead is really in the way jpa
> does way more for you, compare your updates for instance.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-06-20 16:16 GMT+02:00 Steve Goldsmith <sg...@gmail.com>:
>
> > @Stateful was used in both examples, so the impact would have been the
> > same? The real way to find the latency is to profile the code which I
> will
> > do as well.
> >
> > On Tue, Jun 20, 2017 at 10:03 AM, Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > wrote:
> >
> > > not sure what you reference by "string" but JPA needs more round trip
> to
> > be
> > > "hot" (optimized) than dbutils which doesnt pretty much nothing. The
> > state
> > > management etc is also an overhead.
> > >
> > > If you update your example to have a @Version for instance you will
> start
> > > to realize it, then add a small layer to not have to build yourself the
> > > update query and you will see another part etc.
> > >
> > > I would probably recommand you to maybe evaluate this: try with mysql
> to
> > > have some real db latency and compare the db latency to jpa overhead -
> > > and/or try with N threads with hsqldb ;).
> > >
> > > Generally the overhead once tuned is acceptable compared to the DB
> > latency
> > > and you are often in the IO layer and not the runtime layer.
> > >
> > > Side note about the example: i think the goal was to show how to use a
> > > stateful, name is probably not that great :s
> > >
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > >
> > > 2017-06-20 15:58 GMT+02:00 Steve Goldsmith <sg...@gmail.com>:
> > >
> > > > I copied the JPA stuff from the TomEE examples, so if it is not
> > > optimized,
> > > > using the wrong state, scope, etc. then perhaps the example should be
> > > > updated to reflect that. I will try what you recommend and post new
> > > times.
> > > > The data is exactly the same size, so are you saying because the
> > strings
> > > > are not identical there may be a difference? Just trying to
> understand
> > > that
> > > > perspective. I'll just roll both tests into one to use the same data.
> > > >
> > > > On Tue, Jun 20, 2017 at 2:53 AM, Andy Gumbrecht <
> > > agumbrecht@tomitribe.com>
> > > > wrote:
> > > >
> > > > > So just at a super quick glance - Before we start to anything else.
> > > > >
> > > > > You should modify the code to use the same (identical) random data
> > for
> > > > both
> > > > > tests.
> > > > > Add hibernate.jdbc.batch_size = 25 to your persistence.xml
> properties
> > > > > Never use @Stateful unless you really understand why you should,
> i.e.
> > > use
> > > > > @Stateless for your JpaMovies
> > > > > Use entityManager#find rather than a query
> > > > >
> > > > > Hope this is a quick insight, but I'd also be interested to see the
> > > > results
> > > > > on just these few changes.
> > > > >
> > > > > Andy.
> > > > >
> > > > > On 20 June 2017 at 05:31, Laird Nelson <lj...@gmail.com> wrote:
> > > > >
> > > > > > Have you sat down for a good long reading session with
> > > > > > http://java-persistence-performance.blogspot.com/? I found that
> > > site
> > > > > > invaluable.
> > > > > >
> > > > > > Best,
> > > > > > Laird
> > > > > > --
> > > > > > http://about.me/lairdnelson
> > > > > >
> > > > > > On Mon, Jun 19, 2017 at 8:22 PM sgjava <sg...@gmail.com> wrote:
> > > > > >
> > > > > > > I just built a project to compare JPA+Hibernate to a DBUtils
> > > > > > > implementation.
> > > > > > > DBUtils is a lot faster by a large margin. Can anyone tell me
> if
> > > they
> > > > > > have
> > > > > > > tuned JPA to perform better? I used TomEE 7.0.4-SNAPSHOT. I
> could
> > > > live
> > > > > > with
> > > > > > > maybe a 10% difference, but I'm talking about 10 to 10 times
> > > slower!
> > > > > > >
> > > > > > > https://github.com/sgjava/jpavsdbutils
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > View this message in context:
> > > > > > > http://tomee-openejb.979440.n4.nabble.com/JPA-vs-DBUtils-
> > > > > tp4681918.html
> > > > > > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Andy Gumbrecht
> > > > > https://twitter.com/AndyGeeDe
> > > > > http://www.tomitribe.com
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Steven P. Goldsmith
> > > >
> > >
> >
> >
> >
> > --
> > Steven P. Goldsmith
> >
>
--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
Re: JPA vs DBUtils
Posted by Romain Manni-Bucau <rm...@gmail.com>.
not really, @Stateful vs @Stateful + extended persistence context. This is
quite particular more particular. However overhead is really in the way jpa
does way more for you, compare your updates for instance.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2017-06-20 16:16 GMT+02:00 Steve Goldsmith <sg...@gmail.com>:
> @Stateful was used in both examples, so the impact would have been the
> same? The real way to find the latency is to profile the code which I will
> do as well.
>
> On Tue, Jun 20, 2017 at 10:03 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> wrote:
>
> > not sure what you reference by "string" but JPA needs more round trip to
> be
> > "hot" (optimized) than dbutils which doesnt pretty much nothing. The
> state
> > management etc is also an overhead.
> >
> > If you update your example to have a @Version for instance you will start
> > to realize it, then add a small layer to not have to build yourself the
> > update query and you will see another part etc.
> >
> > I would probably recommand you to maybe evaluate this: try with mysql to
> > have some real db latency and compare the db latency to jpa overhead -
> > and/or try with N threads with hsqldb ;).
> >
> > Generally the overhead once tuned is acceptable compared to the DB
> latency
> > and you are often in the IO layer and not the runtime layer.
> >
> > Side note about the example: i think the goal was to show how to use a
> > stateful, name is probably not that great :s
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-06-20 15:58 GMT+02:00 Steve Goldsmith <sg...@gmail.com>:
> >
> > > I copied the JPA stuff from the TomEE examples, so if it is not
> > optimized,
> > > using the wrong state, scope, etc. then perhaps the example should be
> > > updated to reflect that. I will try what you recommend and post new
> > times.
> > > The data is exactly the same size, so are you saying because the
> strings
> > > are not identical there may be a difference? Just trying to understand
> > that
> > > perspective. I'll just roll both tests into one to use the same data.
> > >
> > > On Tue, Jun 20, 2017 at 2:53 AM, Andy Gumbrecht <
> > agumbrecht@tomitribe.com>
> > > wrote:
> > >
> > > > So just at a super quick glance - Before we start to anything else.
> > > >
> > > > You should modify the code to use the same (identical) random data
> for
> > > both
> > > > tests.
> > > > Add hibernate.jdbc.batch_size = 25 to your persistence.xml properties
> > > > Never use @Stateful unless you really understand why you should, i.e.
> > use
> > > > @Stateless for your JpaMovies
> > > > Use entityManager#find rather than a query
> > > >
> > > > Hope this is a quick insight, but I'd also be interested to see the
> > > results
> > > > on just these few changes.
> > > >
> > > > Andy.
> > > >
> > > > On 20 June 2017 at 05:31, Laird Nelson <lj...@gmail.com> wrote:
> > > >
> > > > > Have you sat down for a good long reading session with
> > > > > http://java-persistence-performance.blogspot.com/? I found that
> > site
> > > > > invaluable.
> > > > >
> > > > > Best,
> > > > > Laird
> > > > > --
> > > > > http://about.me/lairdnelson
> > > > >
> > > > > On Mon, Jun 19, 2017 at 8:22 PM sgjava <sg...@gmail.com> wrote:
> > > > >
> > > > > > I just built a project to compare JPA+Hibernate to a DBUtils
> > > > > > implementation.
> > > > > > DBUtils is a lot faster by a large margin. Can anyone tell me if
> > they
> > > > > have
> > > > > > tuned JPA to perform better? I used TomEE 7.0.4-SNAPSHOT. I could
> > > live
> > > > > with
> > > > > > maybe a 10% difference, but I'm talking about 10 to 10 times
> > slower!
> > > > > >
> > > > > > https://github.com/sgjava/jpavsdbutils
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > View this message in context:
> > > > > > http://tomee-openejb.979440.n4.nabble.com/JPA-vs-DBUtils-
> > > > tp4681918.html
> > > > > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Andy Gumbrecht
> > > > https://twitter.com/AndyGeeDe
> > > > http://www.tomitribe.com
> > > >
> > >
> > >
> > >
> > > --
> > > Steven P. Goldsmith
> > >
> >
>
>
>
> --
> Steven P. Goldsmith
>
Re: JPA vs DBUtils
Posted by Steve Goldsmith <sg...@gmail.com>.
@Stateful was used in both examples, so the impact would have been the
same? The real way to find the latency is to profile the code which I will
do as well.
On Tue, Jun 20, 2017 at 10:03 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> not sure what you reference by "string" but JPA needs more round trip to be
> "hot" (optimized) than dbutils which doesnt pretty much nothing. The state
> management etc is also an overhead.
>
> If you update your example to have a @Version for instance you will start
> to realize it, then add a small layer to not have to build yourself the
> update query and you will see another part etc.
>
> I would probably recommand you to maybe evaluate this: try with mysql to
> have some real db latency and compare the db latency to jpa overhead -
> and/or try with N threads with hsqldb ;).
>
> Generally the overhead once tuned is acceptable compared to the DB latency
> and you are often in the IO layer and not the runtime layer.
>
> Side note about the example: i think the goal was to show how to use a
> stateful, name is probably not that great :s
>
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-06-20 15:58 GMT+02:00 Steve Goldsmith <sg...@gmail.com>:
>
> > I copied the JPA stuff from the TomEE examples, so if it is not
> optimized,
> > using the wrong state, scope, etc. then perhaps the example should be
> > updated to reflect that. I will try what you recommend and post new
> times.
> > The data is exactly the same size, so are you saying because the strings
> > are not identical there may be a difference? Just trying to understand
> that
> > perspective. I'll just roll both tests into one to use the same data.
> >
> > On Tue, Jun 20, 2017 at 2:53 AM, Andy Gumbrecht <
> agumbrecht@tomitribe.com>
> > wrote:
> >
> > > So just at a super quick glance - Before we start to anything else.
> > >
> > > You should modify the code to use the same (identical) random data for
> > both
> > > tests.
> > > Add hibernate.jdbc.batch_size = 25 to your persistence.xml properties
> > > Never use @Stateful unless you really understand why you should, i.e.
> use
> > > @Stateless for your JpaMovies
> > > Use entityManager#find rather than a query
> > >
> > > Hope this is a quick insight, but I'd also be interested to see the
> > results
> > > on just these few changes.
> > >
> > > Andy.
> > >
> > > On 20 June 2017 at 05:31, Laird Nelson <lj...@gmail.com> wrote:
> > >
> > > > Have you sat down for a good long reading session with
> > > > http://java-persistence-performance.blogspot.com/? I found that
> site
> > > > invaluable.
> > > >
> > > > Best,
> > > > Laird
> > > > --
> > > > http://about.me/lairdnelson
> > > >
> > > > On Mon, Jun 19, 2017 at 8:22 PM sgjava <sg...@gmail.com> wrote:
> > > >
> > > > > I just built a project to compare JPA+Hibernate to a DBUtils
> > > > > implementation.
> > > > > DBUtils is a lot faster by a large margin. Can anyone tell me if
> they
> > > > have
> > > > > tuned JPA to perform better? I used TomEE 7.0.4-SNAPSHOT. I could
> > live
> > > > with
> > > > > maybe a 10% difference, but I'm talking about 10 to 10 times
> slower!
> > > > >
> > > > > https://github.com/sgjava/jpavsdbutils
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > View this message in context:
> > > > > http://tomee-openejb.979440.n4.nabble.com/JPA-vs-DBUtils-
> > > tp4681918.html
> > > > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Andy Gumbrecht
> > > https://twitter.com/AndyGeeDe
> > > http://www.tomitribe.com
> > >
> >
> >
> >
> > --
> > Steven P. Goldsmith
> >
>
--
Steven P. Goldsmith
Re: JPA vs DBUtils
Posted by Romain Manni-Bucau <rm...@gmail.com>.
not sure what you reference by "string" but JPA needs more round trip to be
"hot" (optimized) than dbutils which doesnt pretty much nothing. The state
management etc is also an overhead.
If you update your example to have a @Version for instance you will start
to realize it, then add a small layer to not have to build yourself the
update query and you will see another part etc.
I would probably recommand you to maybe evaluate this: try with mysql to
have some real db latency and compare the db latency to jpa overhead -
and/or try with N threads with hsqldb ;).
Generally the overhead once tuned is acceptable compared to the DB latency
and you are often in the IO layer and not the runtime layer.
Side note about the example: i think the goal was to show how to use a
stateful, name is probably not that great :s
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2017-06-20 15:58 GMT+02:00 Steve Goldsmith <sg...@gmail.com>:
> I copied the JPA stuff from the TomEE examples, so if it is not optimized,
> using the wrong state, scope, etc. then perhaps the example should be
> updated to reflect that. I will try what you recommend and post new times.
> The data is exactly the same size, so are you saying because the strings
> are not identical there may be a difference? Just trying to understand that
> perspective. I'll just roll both tests into one to use the same data.
>
> On Tue, Jun 20, 2017 at 2:53 AM, Andy Gumbrecht <ag...@tomitribe.com>
> wrote:
>
> > So just at a super quick glance - Before we start to anything else.
> >
> > You should modify the code to use the same (identical) random data for
> both
> > tests.
> > Add hibernate.jdbc.batch_size = 25 to your persistence.xml properties
> > Never use @Stateful unless you really understand why you should, i.e. use
> > @Stateless for your JpaMovies
> > Use entityManager#find rather than a query
> >
> > Hope this is a quick insight, but I'd also be interested to see the
> results
> > on just these few changes.
> >
> > Andy.
> >
> > On 20 June 2017 at 05:31, Laird Nelson <lj...@gmail.com> wrote:
> >
> > > Have you sat down for a good long reading session with
> > > http://java-persistence-performance.blogspot.com/? I found that site
> > > invaluable.
> > >
> > > Best,
> > > Laird
> > > --
> > > http://about.me/lairdnelson
> > >
> > > On Mon, Jun 19, 2017 at 8:22 PM sgjava <sg...@gmail.com> wrote:
> > >
> > > > I just built a project to compare JPA+Hibernate to a DBUtils
> > > > implementation.
> > > > DBUtils is a lot faster by a large margin. Can anyone tell me if they
> > > have
> > > > tuned JPA to perform better? I used TomEE 7.0.4-SNAPSHOT. I could
> live
> > > with
> > > > maybe a 10% difference, but I'm talking about 10 to 10 times slower!
> > > >
> > > > https://github.com/sgjava/jpavsdbutils
> > > >
> > > >
> > > >
> > > > --
> > > > View this message in context:
> > > > http://tomee-openejb.979440.n4.nabble.com/JPA-vs-DBUtils-
> > tp4681918.html
> > > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > > >
> > >
> >
> >
> >
> > --
> > Andy Gumbrecht
> > https://twitter.com/AndyGeeDe
> > http://www.tomitribe.com
> >
>
>
>
> --
> Steven P. Goldsmith
>
Re: JPA vs DBUtils
Posted by Steve Goldsmith <sg...@gmail.com>.
I copied the JPA stuff from the TomEE examples, so if it is not optimized,
using the wrong state, scope, etc. then perhaps the example should be
updated to reflect that. I will try what you recommend and post new times.
The data is exactly the same size, so are you saying because the strings
are not identical there may be a difference? Just trying to understand that
perspective. I'll just roll both tests into one to use the same data.
On Tue, Jun 20, 2017 at 2:53 AM, Andy Gumbrecht <ag...@tomitribe.com>
wrote:
> So just at a super quick glance - Before we start to anything else.
>
> You should modify the code to use the same (identical) random data for both
> tests.
> Add hibernate.jdbc.batch_size = 25 to your persistence.xml properties
> Never use @Stateful unless you really understand why you should, i.e. use
> @Stateless for your JpaMovies
> Use entityManager#find rather than a query
>
> Hope this is a quick insight, but I'd also be interested to see the results
> on just these few changes.
>
> Andy.
>
> On 20 June 2017 at 05:31, Laird Nelson <lj...@gmail.com> wrote:
>
> > Have you sat down for a good long reading session with
> > http://java-persistence-performance.blogspot.com/? I found that site
> > invaluable.
> >
> > Best,
> > Laird
> > --
> > http://about.me/lairdnelson
> >
> > On Mon, Jun 19, 2017 at 8:22 PM sgjava <sg...@gmail.com> wrote:
> >
> > > I just built a project to compare JPA+Hibernate to a DBUtils
> > > implementation.
> > > DBUtils is a lot faster by a large margin. Can anyone tell me if they
> > have
> > > tuned JPA to perform better? I used TomEE 7.0.4-SNAPSHOT. I could live
> > with
> > > maybe a 10% difference, but I'm talking about 10 to 10 times slower!
> > >
> > > https://github.com/sgjava/jpavsdbutils
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > > http://tomee-openejb.979440.n4.nabble.com/JPA-vs-DBUtils-
> tp4681918.html
> > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > >
> >
>
>
>
> --
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
>
--
Steven P. Goldsmith
Re: JPA vs DBUtils
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hmm, you need to take multiple things into account to compare it fairly:
1. as Andy mentionned extended persistence context do way more than what
you compare to so remove the extended and use something which scales like
@ApplicationScoped @Transactional or @Singleton @ConcurrencyManagement(BEAN)
2. you are using JPA with bean validation so maybe deactivate this layer
too - we can enhance it on master
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2017-06-20 8:53 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
> So just at a super quick glance - Before we start to anything else.
>
> You should modify the code to use the same (identical) random data for both
> tests.
> Add hibernate.jdbc.batch_size = 25 to your persistence.xml properties
> Never use @Stateful unless you really understand why you should, i.e. use
> @Stateless for your JpaMovies
> Use entityManager#find rather than a query
>
> Hope this is a quick insight, but I'd also be interested to see the results
> on just these few changes.
>
> Andy.
>
> On 20 June 2017 at 05:31, Laird Nelson <lj...@gmail.com> wrote:
>
> > Have you sat down for a good long reading session with
> > http://java-persistence-performance.blogspot.com/? I found that site
> > invaluable.
> >
> > Best,
> > Laird
> > --
> > http://about.me/lairdnelson
> >
> > On Mon, Jun 19, 2017 at 8:22 PM sgjava <sg...@gmail.com> wrote:
> >
> > > I just built a project to compare JPA+Hibernate to a DBUtils
> > > implementation.
> > > DBUtils is a lot faster by a large margin. Can anyone tell me if they
> > have
> > > tuned JPA to perform better? I used TomEE 7.0.4-SNAPSHOT. I could live
> > with
> > > maybe a 10% difference, but I'm talking about 10 to 10 times slower!
> > >
> > > https://github.com/sgjava/jpavsdbutils
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > > http://tomee-openejb.979440.n4.nabble.com/JPA-vs-DBUtils-
> tp4681918.html
> > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > >
> >
>
>
>
> --
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
>
Re: JPA vs DBUtils
Posted by Andy Gumbrecht <ag...@tomitribe.com>.
So just at a super quick glance - Before we start to anything else.
You should modify the code to use the same (identical) random data for both
tests.
Add hibernate.jdbc.batch_size = 25 to your persistence.xml properties
Never use @Stateful unless you really understand why you should, i.e. use
@Stateless for your JpaMovies
Use entityManager#find rather than a query
Hope this is a quick insight, but I'd also be interested to see the results
on just these few changes.
Andy.
On 20 June 2017 at 05:31, Laird Nelson <lj...@gmail.com> wrote:
> Have you sat down for a good long reading session with
> http://java-persistence-performance.blogspot.com/? I found that site
> invaluable.
>
> Best,
> Laird
> --
> http://about.me/lairdnelson
>
> On Mon, Jun 19, 2017 at 8:22 PM sgjava <sg...@gmail.com> wrote:
>
> > I just built a project to compare JPA+Hibernate to a DBUtils
> > implementation.
> > DBUtils is a lot faster by a large margin. Can anyone tell me if they
> have
> > tuned JPA to perform better? I used TomEE 7.0.4-SNAPSHOT. I could live
> with
> > maybe a 10% difference, but I'm talking about 10 to 10 times slower!
> >
> > https://github.com/sgjava/jpavsdbutils
> >
> >
> >
> > --
> > View this message in context:
> > http://tomee-openejb.979440.n4.nabble.com/JPA-vs-DBUtils-tp4681918.html
> > Sent from the TomEE Users mailing list archive at Nabble.com.
> >
>
--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
Re: JPA vs DBUtils
Posted by Laird Nelson <lj...@gmail.com>.
Have you sat down for a good long reading session with
http://java-persistence-performance.blogspot.com/? I found that site
invaluable.
Best,
Laird
--
http://about.me/lairdnelson
On Mon, Jun 19, 2017 at 8:22 PM sgjava <sg...@gmail.com> wrote:
> I just built a project to compare JPA+Hibernate to a DBUtils
> implementation.
> DBUtils is a lot faster by a large margin. Can anyone tell me if they have
> tuned JPA to perform better? I used TomEE 7.0.4-SNAPSHOT. I could live with
> maybe a 10% difference, but I'm talking about 10 to 10 times slower!
>
> https://github.com/sgjava/jpavsdbutils
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/JPA-vs-DBUtils-tp4681918.html
> Sent from the TomEE Users mailing list archive at Nabble.com.
>