cancel
Showing results for 
Search instead for 
Did you mean: 

ejb performance

werner_dornacher
Explorer
0 Kudos

Hello,

I've got a MySQL db with ~ 1500 rows. When doing a select through an entity ejb it take ~2500ms to execute a given request. It takes ~250 ms when I access the data base directly on the client. My ejb is ten times slower than a direct access by the client, is that normal? My bean is on a WEB AS in debug mode is that the problem? It seems that the "ejbStore" method is called for each result when I call a find method, why?

Best regards

Werner.

Accepted Solutions (0)

Answers (2)

Answers (2)

Benny
Product and Topic Expert
Product and Topic Expert
0 Kudos

Besides the other recommendations about architecture it is a clear YES abotu debugging slowing down your application. NEVER do performance testing in debug state.

Regards,

Benny

Former Member
0 Kudos

Werner,

We have an existing application that began with +- 50 entity beans. As the application was being built, they appeared to work well with the sample data in oracle. But...when it hit production, and volume became a factor, the entity beans, in some situations, were disastrous. They performed terribly. Since the application's first deployment, about 4-5 years ago, we've had to methodically replace many of them that were behaving as bottlenecks.

This behaviour has been observed by many, including some IBM experts who were auditing our application, who insisted that we no longer use entity beans because of their performance.

My observations:

Entity beans seem to do ok for updating the db, because most of the time there are only a few objects to save...However, extracting data has always been more complicated. If you use entity beans (especially with table mapping), it becomes long and arduous to navigate the db scheme using entity beans because often you have to create lots of them in order to get a simple list of items which have been moderately normalised in the db.

In order to benefit from the transactional aspects of EJB's we have adopted the SessionFacade (session stateless) pattern. This way we pass ValueObjects back and forth from the session facade. Stateless Session beans still suffer from the EJB framework overhead, but often the container keeps them alive so they do not have to be instanciated as often as an entity bean. With this method, however, we have to write our own SQL's...but in the case of data extranction, specific/personalized SQL's will always outgun generated SQL's.

Just some ideas,

Mark