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 <[email protected]> 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 <[email protected]>: > > > 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 < > [email protected] > > > > > 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 <[email protected]>: > > > > > > > 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
