Re: [JBoss-user] CMRs are Slow (was: Entity Bean Performance Tuning Help)
With that attitude I doubt this will get the kind of attention you probably want it to... This is open source. Dain spent countless hours creating the damn thing... Maybe a little bit of your time in OptimizeIt helping the cause would kill you... But I doubt it. > From: "Luttrell, Peter" <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > Date: Thu, 7 Nov 2002 10:14:16 -0600 > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > Subject: RE: [JBoss-user] CMRs are Slow (was: Entity Bean Performance Tuni ng > Help) > > I'll leave you to debug and optimize your own code. > > .peter > > -Original Message- > From: Dain Sundstrom [mailto:dain@;daingroup.com] > Sent: Wednesday, November 06, 2002 8:53 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] CMRs are Slow (was: Entity Bean Performance > Tuni ng Help) > > > Well, it should be fast then. Now is when you fire up OptimizeIt and > findout what part of my code is wasting all that time. > > -dain > > Luttrell, Peter wrote: >> No i did not see that email. >> >> I am using commit option A. The first time that I run through all beans, > the >> main ones as well as the relationship ones should all get cached, right? >> >> If this is correct then my question stands because the times that i posted >> were the 4th read. >> >> Please see the code that I posted with the original message. I think you >> might have been the one who asked for the sample. >> >> .peter >> >> -Original Message- >> From: Dain Sundstrom [mailto:dain@;daingroup.com] >> Sent: Wednesday, November 06, 2002 5:39 PM >> To: [EMAIL PROTECTED] >> Subject: Re: [JBoss-user] CMRs are Slow (was: Entity Bean Performance >> Tuni ng Help) >> >> >> Did you miss my email? It is slow because there is no way to readahead >> across a cmr on-find in response to a query. This will eventually be >> in, but it is not not, so you get a query for each cmr you load. If you >> use commit option A all data will be eventually be cached so it will be >> fast. In future release the readahead will be more flexible. >> >> -dain >> >> Luttrell, Peter wrote: >> >>> Changing the readahead strategy should not change the results i've >>> posted, as i run though the beans once, hense they are loaded. >>> >>> So back to the questions: Is it acceptable that adding 2 cmrs takes 450% >>> the time >>> >>>-Original Message- >>>From: Herve Tchepannou [mailto:htchepannou@;objexis.com] >>>Sent: Tuesday, November 05, 2002 3:38 PM >>>To: [EMAIL PROTECTED] >>>Subject: RE: [JBoss-user] CMRs are Slow (was: Entity Bean >>>Performance Tuni ng Help) >>> >>>1. What's the read-ahead/strategy of findAll() ? Since you want to >>>get all the beans value object, it should be set to on-find, >>>otherwhise, you are going to have the N+1 finder problem >>>2. Since you're populating the ValueObject with the content of your >>>CMR fields, because each access to the CMR fields will call their >>>findByPrimaryKey() to load them. Me, I always load CMR when needed. >>>If they are always needed, then I use de Dependant Value Class >>>3. Internal/External ValueObject creation. This make sense because >>>in the external, each call of a getter from the ValueObject passes >>>via the beanProxy (+ interceptors), where in the internal case you >>>are already in the bean, then no overhead of the beanProxy >>>4. It may be interesting to see the result if you load all the 1000 >>>beans, but return just a page of 25 ValueObjects, which is how most >>>web-pages works to avoid those performance problems - then, make >>>sure that the read-ahead strategy of the findAll() is set to on-load >>> >>>-Original Message- >>>From: Luttrell, Peter [mailto:PLuttrell@;starkinvestments.com] >>>Sent: Tuesday, November 05, 2002 4:00 PM >>>To: '[EMAIL PROTECTED]' >>>Subject: [JBoss-user] CMRs are Slow (was: Entity Bean Performance >>>Tuning Help) >>> >>>The "Entity Bean Performance Tuning Help" thread went off in >>>various different directions. The thread begged a sample and a >>>little more detail as to what was slow. I've identified the >>>problem to be (CMRs) and provided a full sample
RE: [JBoss-user] CMRs are Slow (was: Entity Bean Performance Tuning Help)
1. What's the read-ahead/strategy of findAll() ? Since you want to get all the beans value object, it should be set to on-find, otherwhise, you are going to have the N+1 finder problem 2. Since you're populating the ValueObject with the content of your CMR fields, because each access to the CMR fields will call their findByPrimaryKey() to load them. Me, I always load CMR when needed. If they are always needed, then I use de Dependant Value Class 3. Internal/External ValueObject creation. This make sense because in the external, each call of a getter from the ValueObject passes via the beanProxy (+ interceptors), where in the internal case you are already in the bean, then no overhead of the beanProxy 4. It may be interesting to see the result if you load all the 1000 beans, but return just a page of 25 ValueObjects, which is how most web-pages works to avoid those performance problems - then, make sure that the read-ahead strategy of the findAll() is set to on-load -Original Message-From: Luttrell, Peter [mailto:[EMAIL PROTECTED]]Sent: Tuesday, November 05, 2002 4:00 PMTo: '[EMAIL PROTECTED]'Subject: [JBoss-user] CMRs are Slow (was: Entity Bean Performance Tuning Help) The "Entity Bean Performance Tuning Help" thread went off in various different directions. The thread begged a sample and a little more detail as to what was slow. I've identified the problem to be (CMRs) and provided a full sample (attached). Lets rehash what i'm testing: The code runs inside of a SSB with a transaction on each method vs servlet (struts action) + manual transaction as in the real app. I use hypersonic vs oracle in my real app. calls findAll() dumps out the time iterates through each calling all methods and building a valueobject. this should cache all results (checkout my jboss.xml) iterates through each calling all methods and building a valueobject (a 2nd time) dumps out the time iterates through each and calling 1 method on ejb, which builds the valueobject internally dumps out the time I'm mostly concerned with the last time, as it's what i do in my real case...because it's the fastest. The entitybean has 2 CMRs. The read-all+fields time for 1000 cached beans using internal valueobject generation takes about 670ms. But with 1 cmr it only takes 350ms. And with No cmrs it only takes 150ms. [if you want slightly modified code, let me know]. Now 150ms is great! But 350 isn't. It's more then double. Is this acceptable? Add a few more and it's unusable for a lot of applications. Arguably cmp EntityBeans were worthless till ejb2.0 and CMRs came along. But to actually use them in JBoss is suicide for performance. The attached sample has a test class called "Test", which can be run with -c to generate 1000 test rows. Also included is an ant script which builds the test beans and deploys them to jboss, if you set your jboss.install path in build.properties. Here the actual output from my last test run: 14:31:36,312 INFO [STDOUT] creating 1000 Blobs...14:31:43,968 INFO [STDOUT] Creation complete, took 7656ms.14:31:46,328 INFO [STDOUT] testing retrival speed...14:31:46,328 INFO [STDOUT] Initial Retrival, beans may or maynot be in cache.14:31:46,375 INFO [STDOUT] finder took 47ms.14:31:49,140 INFO [STDOUT] External ValueObject creation took 2765ms for 1000 objects.14:31:49,859 INFO [STDOUT] Internal ValueObject creation took 719ms for 1000 objects.14:31:49,859 INFO [STDOUT] Secondary Retrival, beans are in cache.14:31:50,125 INFO [STDOUT] finder took 266ms.14:31:52,765 INFO [STDOUT] External ValueObject creation took 2640ms for 1000 objects.14:31:53,437 INFO [STDOUT] Internal ValueObject creation took 672ms for 1000 objects. These results also beg the question of why the interceptor stack takes so long to transversion, hense the extra 2000ms for 1000s ejbs, but lets leave that for a seperate thread. .peter This transmission contains information solely for intended recipient and may be privileged, confidential and/or otherwise protect from disclosure. If you are not the intended recipient, please contact the sender and delete all copies of this transmission. This message and/or the materials contained herein are not an offer to sell, or a solicitation of an offer to buy, any securities or other instruments. The information has been obtained or derived from sources believed by us to be reliable, but we do not represent that it is accurate or complete. Any opinions or estimates contained in this information constitute our judgment as of this dat
[JBoss-user] CMRs are Slow (was: Entity Bean Performance Tuning Help)
The "Entity Bean Performance Tuning Help" thread went off in various different directions. The thread begged a sample and a little more detail as to what was slow. I've identified the problem to be (CMRs) and provided a full sample (attached). Lets rehash what i'm testing: The code runs inside of a SSB with a transaction on each method vs servlet (struts action) + manual transaction as in the real app. I use hypersonic vs oracle in my real app. calls findAll() dumps out the time iterates through each calling all methods and building a valueobject. this should cache all results (checkout my jboss.xml) iterates through each calling all methods and building a valueobject (a 2nd time) dumps out the time iterates through each and calling 1 method on ejb, which builds the valueobject internally dumps out the time I'm mostly concerned with the last time, as it's what i do in my real case...because it's the fastest. The entitybean has 2 CMRs. The read-all+fields time for 1000 cached beans using internal valueobject generation takes about 670ms. But with 1 cmr it only takes 350ms. And with No cmrs it only takes 150ms. [if you want slightly modified code, let me know]. Now 150ms is great! But 350 isn't. It's more then double. Is this acceptable? Add a few more and it's unusable for a lot of applications. Arguably cmp EntityBeans were worthless till ejb2.0 and CMRs came along. But to actually use them in JBoss is suicide for performance. The attached sample has a test class called "Test", which can be run with -c to generate 1000 test rows. Also included is an ant script which builds the test beans and deploys them to jboss, if you set your jboss.install path in build.properties. Here the actual output from my last test run: 14:31:36,312 INFO [STDOUT] creating 1000 Blobs...14:31:43,968 INFO [STDOUT] Creation complete, took 7656ms.14:31:46,328 INFO [STDOUT] testing retrival speed...14:31:46,328 INFO [STDOUT] Initial Retrival, beans may or maynot be in cache.14:31:46,375 INFO [STDOUT] finder took 47ms.14:31:49,140 INFO [STDOUT] External ValueObject creation took 2765ms for 1000 objects.14:31:49,859 INFO [STDOUT] Internal ValueObject creation took 719ms for 1000 objects.14:31:49,859 INFO [STDOUT] Secondary Retrival, beans are in cache.14:31:50,125 INFO [STDOUT] finder took 266ms.14:31:52,765 INFO [STDOUT] External ValueObject creation took 2640ms for 1000 objects.14:31:53,437 INFO [STDOUT] Internal ValueObject creation took 672ms for 1000 objects. These results also beg the question of why the interceptor stack takes so long to transversion, hense the extra 2000ms for 1000s ejbs, but lets leave that for a seperate thread. .peter This transmission contains information solely for intended recipient and may be privileged, confidential and/or otherwise protect from disclosure. If you are not the intended recipient, please contact the sender and delete all copies of this transmission. This message and/or the materials contained herein are not an offer to sell, or a solicitation of an offer to buy, any securities or other instruments. The information has been obtained or derived from sources believed by us to be reliable, but we do not represent that it is accurate or complete. Any opinions or estimates contained in this information constitute our judgment as of this date and are subject to change without notice. Any information you share with us will be used in the operation of our business, and we do not request and do not want any material, nonpublic information. Absent an express prior written agreement, we are not agreeing to treat any information confidentially and will use any and all information and reserve the right to publish or disclose any information you share with us. entitybean-withcmr-perf-test.zip Description: Binary data
