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