Are JBoss and Entity Beans so slow?

[jdwn]

Hello,

I've tested a bit the performance and Entity beans. I executed a list, which had to get 600 records from the DB and put them in entity beans. If I execute 1 get method on each entity, the performance is below 100ms. If I execute 7 or more getter methods on each entity the performance goes above 150 ms. This is strange because the entity is in cache, so the getters should be executed very fast. I'm using commit option A and to test all this I'm running on a 3Ghz., with 1GB ram.

I also tried to update (calling a setter) some of the cached entity beans and then the performance is even worse!

To give an idea, I need to list and access 600 records and update at least 300 of them in less than 200ms. In the same time I need to perform some business logic.
Can somebody help? Or is there some configuration thing I forgot about?

Thnx a lot!

[juha]

CMP optimizations are covered in the documentation.

[jdwn]

I've already done some optimization using read-ahead and load-groups, but not a big improved result. So here some strange things I noticed:
If I'm using a standard CMP Entity bean, why is ejbStore called each time I execute a getter method, and how can I turn this off?
Is it possible to do all these operations in less then 300ms. using entity beans, or should I take a look at other technologies?
How can I be sure that the entity beans are cached?

Thnx a lot!

[camel]

http://jboss.org/jbossBlog/blog/bburke/?permalink=Optimizing+JBoss%3A+Experiences+with+SPECj2002.html

[jdwn]

Thank you for the url. I tried the proposed performance enhancements and got some better results. But not the results I expect.
If I access one field of the entity the performance is ok (around 50ms.), but if I access several fields, the execution time is still around 150 ms. and too much in my opinion.

The same I have for the update operation. Calling one setter for each entity, gives me around 40ms. for 300 entities in total. This is ok, but when I do this for several fields the execution time becomes above 150 ms.

Actually I expect around 50 ms. for a list with 600 entities, where we access all the fields. For the update I expect around 80 ms. for an update of 300 entities, where we update 50% of the fields of each entity.

Does somebody know if this is reachable with entity beans and JBoss?

Thnx!
Joris

[fbiaggi]

Hi,
just my cent,
witch RDB are you using ?
Try MySQL to see if there is a difference.

Ciao.

[juha]

"jdwn" wrote:
If I'm using a standard CMP Entity bean, why is ejbStore called each time I execute a getter method, and how can I turn this off?

Search the CMP forum for dirty checking options or look into the CMP DTD for the config tags.

[jdwn]

First of all, I'm using MySQL, so that ain't the problem I think.
I've set the <check-dirty-after-get> option with the folowing result: for the list of 600 entities (accessing 7 fields) I get 156 ms. For the update of 300 entities (setting 7 fields) I get 140 ms.

I noticed that the ejbStore operations are gone in the list operation, but the performance gain is minimal.
Is somebody having a final solution?

Thnx,
Joris

[juha]

"jdwn" wrote:

Is somebody having a final solution?

Post yopur code, I'm not going to start guessing what you're doing wrong or where you can optimize.

Not that I'm going to spend more than 2 seconds reading your code either, but maybe someone else will.

[jdwn]

I've put my source files into my EJB jar which you can find on:
http://users.pandora.be/De.Winne/TestEJB.jar

For my entity bean I'm using the folowing configuration:
<container-configuration>
<container-name>Standard CMP 2.x EntityBean</container-name>
<call-logging>false</call-logging>
<invoker-proxy-binding-name>entity-rmi-invoker</invoker-proxy-binding-name>
<sync-on-commit-only>true</sync-on-commit-only>
<insert-after-ejb-post-create>false</insert-after-ejb-post-create>
<container-interceptors>
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor
org.jboss.ejb.plugins.LogInterceptor
org.jboss.ejb.plugins.SecurityInterceptor
org.jboss.ejb.plugins.TxInterceptorCMT
org.jboss.ejb.plugins.MetricsInterceptor
org.jboss.ejb.plugins.EntityCreationInterceptor
org.jboss.ejb.plugins.EntityLockInterceptor
org.jboss.ejb.plugins.EntityInstanceInterceptor
org.jboss.ejb.plugins.EntityReentranceInterceptor
org.jboss.resource.connectionmanager.CachedConnectionInterceptor
org.jboss.ejb.plugins.EntitySynchronizationInterceptor
org.jboss.ejb.plugins.cmp.jdbc.JDBCRelationInterceptor
</container-interceptors>
<instance-pool>org.jboss.ejb.plugins.EntityInstancePool</instance-pool>
<instance-cache>org.jboss.ejb.plugins.InvalidableEntityInstanceCache</instance-cache>
<persistence-manager>org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager</persistence-manager>
<locking-policy>org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock</locking-policy>
<container-cache-conf>
<cache-policy>org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy</cache-policy>
<cache-policy-conf>
<min-capacity>50</min-capacity>
<max-capacity>1000000</max-capacity>
<overager-period>300</overager-period>
<max-bean-age>600</max-bean-age>
<resizer-period>400</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>
1000
</container-pool-conf>
<commit-option>A</commit-option>
</container-configuration>

I hope somebody can take a look, and can explain me why increasing the number of get or set operations on an entity bean, also increases the execution time a lot.

Thnx!

[dhartford]

Here's some things to try:

1. Check the database (straight SQL). Make sure you have indexed appropriately for your finders/ejbSelects. If the database is slow, there is nothing you can do on the Application Server (Jboss) side that will speed things up.

2. Check your database again and get metrics. For each finder and ejbSelect, write a similar SQL and run it with 'EVALUATE' or similar context in your database server. See how fast it is in regular database compared to your results from the application server. If you have access to a DBA (for whatever RDBMS you are using), use their services to optimize the database and then go back to optimizing your application based from the best database you have access to.

3. Then, you can look into Commit Options and Optimistic Locking on the Container side for your CMP beans.

4. Transaction settings for your methods.

5. Watching for ejbStore is a good thing as you have. Finders and ejbSelects are required by spec to call ejbStore, no way around it. As for each 'getXXX' calling ejbStore, may be related to using a local reference - look into Value-Objects to speed things up later down the pipeline.

6. Although unlikely it should still be looked at - the network connection to your database (if not running local).

There are some things that may help out based on your symptoms, good luck!

-D

[jdwn]

First of all thanks for the possible things to try, but:

Point 1.: I've written the fast lane reader on the same DB, and my performance is then 5-6 times better. So I don't think my DB is slow.

Point 2.: As my DB is fast enough, I didn't get metrics.

Point 3.: I've commit option A (the fastest), I tried optimistic locking and even load groups

Point 4.: My transaction level is set to required

Point 5.: I solved the ejbStore for the getXXX methods, but it didn't gave me any performance gain

Point 6. My DB is on the same machine as my JBoss.

So, I can use DAO for my read operation of 600 records, but what when I want to write 300 of them to the DB, using several calls to setXXX methods?

Anyway thnx, for the advice!
Still hoping for some good solution!

Joris

[amayingenta]

CMP is usually going to be slower than direct JDBC access - so I'm not surprised that you're finding it 5-6 times slower in some cases.

The container has to do a lot more work (object creation, pooling, worrying about transactions etc.) than a simple bit of JDBC access.

CMP has it's advantages in terms of ease of use and development, but it's not necessarily fast, and in particular I don't think it's suited to bulk reading/writing of data. I recently replaced a bit of code that read up to 3000 records via CMP/CMR, and it's at least 10 times quicker using JDBC.

Anyway, that's my 2 cents

-Andrew

[jdwn]

I agree that Entity beans are slow! So for bulky reads it's good to use direct JDBC calls. But what with bulky writes? The problem gets even bigger when 50% of the readed records using JDBC, needs to be written back to the DB. Entity beans are to be created while we already have the record using a JDBC call.

Does somebody know if Hibernate is a good alternative for bulky write operation and does somebody have some benchmarks, giving the difference between entity beans and Hibernate.

Are there other sollutions for the persistence layer then entity beans and Hibernate?

Thnx!
I'm still hoping on a persistence layer that performs well (and ain't direct JDBC) :-)

[efrinmn]

For information about Hibernate, you could try either their website: http://www.hibernate.org/, or Bruce Tate [e-mail](www.2life.com). He has been giving seminars on Hibernate through the "No Fluff Just Stuff Java Symposium" (http://www.nofluffjuststuff.com/index.jsp). I attended the Minneapolis/St Paul symposium and although I was not really interested in Hibernate, I recall quite a few folks were and I did not hear anything disparaging said about it.