JBoss is losing credibility in our firm due to this performance problem as well as the issues i've noted about JMS performance.
If anyone cares whether JBoss is actually used in the production environment, the team might consider investing time in making it perform well. .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
