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 <rmannibu...@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 <sgj...@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
