Hi JBoss friends, I tend to agree with Bill and Dain's last posting here. There are certain things that CMP is not designed to do *well* and large, heavy reads is one of them.
I'd venture to guess the same performance problem will occur on other app servers, in which case, it is not a war of servers, but a principle of application design (SSB+JDBC vs. CMP). If the numbers come in much better from testing on other app servers, we need to get JBoss "fixed". Until then, I'd recommend a different approach than CMP. Jason -----Original Message----- From: [EMAIL PROTECTED] [mailto:jboss-user-admin@;lists.sourceforge.net]On Behalf Of Bill Burke Sent: Tuesday, October 29, 2002 10:28 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help JBoss is being used in production everywhere. I've been at 6 sites myself over the past year. IMHO and experience, entity beans are not the right choice if you're doing complex reporting. A handmade query cache with direct JDBC will always be faster. Besides, EJB QL doesn't have Group By. My bet is that it is a problem with your code More comments inlined. > I have a method, which does this: > > 1) begin manual transaction with jta > > 2) calls findBySomeCriteria() which returns some 750 ejbs > ->takes 200-300ms (good) > Entities not loaded yet... > 3) then iterate through each, calling one of the methods > i do this to fill the readahead cache for all the beans in an > attempt to isolate the performance problem > ->takes 80-100ms (good) > Entites are loaded by this time. This leads me to believe it is your DataObject creation that is slow. More comments follow... > 4) then iterate through each, and constructing a dataobject that I > use for display purposes > ->takes 2000-2500ms (this seams way too long) > > 5) commit the transaction, blablabla.. > > I used 2 other non-ejb solutions to get what I needed done. > > Cache the dataobjects in the webtier. It will only work in certain cases, > 2/3 in my case. I know it's duplicating work that the ejb > container should > do, Why should the EJB tier be responsible for caching your DataObjects? Unless you explicitly code this in ejbLoad, only persistent fields are stored. > but if there is noting that can be done to JBoss to get performance > acceptable then... > Try another app server then. I'd be curious to see if it is much faster. Bill > Paginate the results. Checkout this taglib, it does it all for you > automatically: http://edhill.its.uiowa.edu/display/. Plus my users like it > better because IE can render the pages very fast, compared to the > super long > time it takes with large tables. > > .peter > > -----Original Message----- > From: Georg Schmid [mailto:georg-schmid@;ti.com] > Sent: Tuesday, October 29, 2002 2:23 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help > > > > First of all: > > This was only an experiment to check the impact of the > EntitySynchronizationInterceptor on performance. > Of course this is nothing you should do in a real setup. I know what the > EntitySynchronizationInterceptor is for. > > I have been using JBoss for almost a year, reading almost all posts on > the Jboss dev, user and cvs mailing lists, as well as searching the > forums regulary, if I have an issue to solve. > > My problem is: Creating value objects through calling a method on an > CMP2.0 entity bean takes 3 to 10 times more time than walking through an > equivalent result set of a 'raw' JDBC query. I tried to dig into this > issue by stripping down the interceptor stack !as an experiment! to the > bare minimum. The result of this experiment was, that the > EntitySynchronizationInterceptor is the only interceptor, that changes > performance significantly in my setup. Removing the transaction or > security interceptors did not have any significant impact. > > Getting the data from the database into the Jboss server memory is not > the problem. The finder I am using for testing returns a result set with > 1000 rows. It uses the default load group. This means that all data is > in memory after the finder has completed, which takes only a few hundred > milliseconds, just like issuing a "select * from BeanTable". For this > reason playing around with page sizes and load groups etc. is pointless. > My experience is that locking has no measurable effect on the > performance (the performance test is strictly single-user). > > The time is lost when I walk through the collection of entity beans > returned by the finder and call a method on each to create the value > objects (one method call per value object). Others have come to the same > conclusion, but I have not found a post that points to a solution of > this problem. > > I really would like to be able to do a web page, that displays at most > about 4000 rows, using entity beans and CMP2.0. But with the current > performance I have to switch to direct JDBC calls in my stateless > session beans every time I have to display more than 500 rows (Jboss > 3.0.3 running on a dual UltraSparcIII with 4GB memory and an Oracle db > on similar hardware). > > This is the issue I am trying to solve. If you could help me with that > I'd really appreciate it. > Thanks. > > Regards > Georg > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:jboss-user-admin@;lists.sourceforge.net] On Behalf Of Bill Burke > Sent: Tuesday, October 29, 2002 07:24 > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help > > > Georg stop spewing nonsense....Never ever take out the synchronization > interceptor! It registers synchronzations with the TM so that the > entity bean changes get committed! Please read the for-pay docs or > review the archives. I have explained this shit over and over. > > I've added a EntityLockMonitor MBean to 3.0.4 and higher. Look in > jboss-service.xml to uncomment it. Gives you # contentions in table > with bean beans. Also gives averages and other stats. I'll be adding > this to docs eventually. > > Bill > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:jboss-user-admin@;lists.sourceforge.net]On Behalf Of Georg > > Schmid > > Sent: Monday, October 21, 2002 4:32 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-user] Entity Bean Performance Tuning Help > > > > > > Peter, > > > > I have a similar problem and tried to dig into it. > > You may have a look at the thread > > http://www.jboss.org/forums/thread.jsp?forum=46&thread=20827 in the > > forums. > > > > To summarize: the EB caching works perfectly (I guess it is as fast as > > > you can get with JDBC), but getting the rows in memory into a data or > > value object is slow. Creating n value objects for n EB instances > > involves going through the interceptor stack n times, and this is, > > where the time is lost. > > > > I incrementally stripped down the interceptor stack using a custom > > configuration in my jboss.xml, but without much success. > > > > The only way to really speed up things that I found was removing the > > synchronization interceptor, which improves performance by a factor of > > > 2, if no or only one attribute is read, but makes it worse, if many > > attributes have to be read. > > > > BTW: I used commit option B, read-ahead on-load, and the Instance Per > > Transaction setup in my experiments. > > > > The pattern you found is interesting. Because there are so many things > > > impacting the performance, it is hard to tell, whom to ask (Dain, > > Bill, David,...). > > > > Bill Burke did some performance tests using ECPerf. Maybe he can > > report a bit on the results. > > > > Regards > > Georg > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:jboss-user-admin@;lists.sourceforge.net] On Behalf Of Luttrell, > > > Peter > > Sent: Saturday, October 19, 2002 02:17 > > To: '[EMAIL PROTECTED]' > > Subject: [JBoss-user] Entity Bean Performance Tuning Help > > > > > > I have something that is taking longer then I would like and am trying > > > to tune jboss to reduce the time it takes. > > > > My test scenario is as such: > > > > JBoss3.0.3 on jdk1.4.1_01 > > 1 2.0 CMP Enity bean with about 10 fields and 3 relationships. I'm > > using commit-option A so all beans should be cached (see cache policy > > below) once loaded. The first time that I run this it obviously takes > > longer (filling the cache), however subsequent times aren't as fast as > > > i would like; see > > below: > > > > I have a method, which does this: > > > > 1) begin manual transaction with jta > > > > 2) calls findBySomeCriteria() which returns some 750 ejbs > > ->takes 200-300ms (good) > > > > 3) then iterate through each, calling one of the methods > > i do this to fill the readahead cache for all the beans in an > > attempt to isolate the performance problem > > ->takes 80-100ms (good) > > > > 4) then iterate through each, and constructing a dataobject that I > > > use for display purposes > > ->takes 2000-2500ms (this seams way too long) > > > > 5) commit the transaction, blablabla.. > > > > The problem is step 4 seams to be taking longer then it should. > > > > I then added some trace to the dataobject constructor method, where I > > basically pass in a reference to the ejb and call most of the methods > > on it. The trace dumps out the total time the constructor took. I > > noticed a weird pattern. Most of the constructions took 0ms, but every > > > 5th or so it took 15-16ms, which is where all of my time is going. > > Note that it is not exactly every 5th and tends to vary a bit. Here's > > a sample of the > > output: > > > > 18:46:06,840 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,840 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,840 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,840 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,855 INFO [STDOUT] displayBean construction took 15 ms > > 18:46:06,855 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,855 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,855 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,855 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,871 INFO [STDOUT] displayBean construction took 16 ms > > 18:46:06,871 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,871 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,871 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,871 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,886 INFO [STDOUT] displayBean construction took 15 ms > > 18:46:06,886 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,886 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,886 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,886 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,902 INFO [STDOUT] displayBean construction took 16 ms > > 18:46:06,902 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,902 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,902 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,902 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,918 INFO [STDOUT] displayBean construction took 16 ms > > 18:46:06,918 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,918 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,918 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,918 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,933 INFO [STDOUT] displayBean construction took 15 ms > > 18:46:06,933 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,933 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,933 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,949 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,949 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,965 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,965 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,965 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,965 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,965 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,980 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,980 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,980 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,980 INFO [STDOUT] displayBean construction took 0 ms > > 18:46:06,996 INFO [STDOUT] displayBean construction took 16 ms > > > > my ejb-jar.xml file: > > > > I have not declared any security-constraints for the bean. > > I have tried it with transactions on and off (Required/Supports), > > which effected performance a little but did not correct the delays i'm > > > seeing. > > > > my jboss.xml > > > > I have the bean tied to a custom container config. Here's the custom > > config, which i basically copied directly from the standardjboss.xml > > file. Note the changes to the cache capacity and age, etc. This is > > intended to keep the beans in the cache. > > > > <container-configurations> > > <container-configuration> > > <container-name>LongLasting Large CMP 2.x EntityBean > > Cache</container-name> > > <call-logging>false</call-logging> > > > > > <container-invoker>org.jboss.proxy.ejb.ProxyFactory</container-invoker> > > <container-interceptors> > > <interceptor>org.jboss.ejb.plugins.LogInterceptor</interceptor> > > > <interceptor>org.jboss.ejb.plugins.SecurityInterceptor</interceptor> > > <interceptor>org.jboss.ejb.plugins.TxInterceptorCMT</interceptor> > > <interceptor metricsEnabled = > > "true">org.jboss.ejb.plugins.MetricsInterceptor</interceptor> > > > > <interceptor>org.jboss.ejb.plugins.EntityCreationInterceptor</intercep > > to > > r> > > > > <interceptor>org.jboss.ejb.plugins.EntityLockInterceptor</interceptor> > > > > <interceptor>org.jboss.ejb.plugins.EntityInstanceInterceptor</intercep > > to > > r> > > > > <interceptor>org.jboss.resource.connectionmanager.CachedConnectionInte > > rc > > eptor</interceptor> > > > > <interceptor>org.jboss.ejb.plugins.EntitySynchronizationInterceptor</i > > nt > > erceptor> > > > > <interceptor>org.jboss.ejb.plugins.cmp.jdbc.JDBCRelationInterceptor</i > > nt > > erceptor> > > </container-interceptors> > > <client-interceptors> > > <home> > > <interceptor>org.jboss.proxy.ejb.HomeInterceptor</interceptor> > > <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor> > > <interceptor>org.jboss.proxy.TransactionInterceptor</interceptor> > > > <interceptor>org.jboss.invocation.InvokerInterceptor</interceptor> > > </home> > > <bean> > > <interceptor>org.jboss.proxy.ejb.EntityInterceptor</interce ptor> > > <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor> > > <interceptor>org.jboss.proxy.TransactionInterceptor</interceptor> > > > <interceptor>org.jboss.invocation.InvokerInterceptor</interceptor> > > </bean> > > <list-entity> > > > > <interceptor>org.jboss.proxy.ejb.ListEntityInterceptor</interceptor> > > <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor> > > <interceptor>org.jboss.proxy.TransactionInterceptor</interceptor> > > > <interceptor>org.jboss.invocation.InvokerInterceptor</interceptor> > > </list-entity> > > </client-interceptors> > > &nb > > sp;<instance-pool>org.jboss.ejb.plugins.EntityInstancePool</instance-p > > oo > > l> > > > > <instance-cache>org.jboss.ejb.plugins.EntityInstanceCache</instance-ca > > ch > > e> > > > > <persistence-manager>org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager</ > > pe > > rsistence-manager> > > <transaction-manager>org.jboss.tm.TxManager</transaction-manager> > > > > <locking-policy>org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock</l > > oc > > king-policy> > > <container-cache-conf> > > > > <cache-policy>org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy</c > > ac > > he-policy> > > <cache-policy-conf> > > <min-capacity>50</min-capacity> > > <max-capacity>10000</max-capacity> > > <overager-period>100000</over ager-period> > > <max-bean-age>31536000</max-bean-age> > > <resizer-period>100000</resizer-period> > > <max-cache-miss-period>60</max-cache-miss-period> > > <min-cache-miss-period>1</min-cache-miss-period> > > <cache-load-factor>0.75</cache-load-factor> > > </cache-policy-conf> > > </container-cache-conf> > > <container-pool-conf> > > <MaximumSize>100</MaximumSize> > > </container-pool-conf> > > <commit-option>A</commit-option> > > </container-configuration> > > </container-configurations> > > > > > > I have also tried replacing the one of the other cache policies > > (org.jboss.ejb.plugins.NoPassivationCachePolicy) and recieved no > > differnet results. > > > > Am i doing something glaringly wrong? > > Can anyone suggest what else to try to get the times down? > > > > thanks. > > .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. > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > JBoss-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > 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. > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
