Fog Creek Software
Discussion Board




EJB Performance

I am supporting a Powerbuilder App about 10 years old that is being replaced by an EJB/JSP web based app. The new app requires 5-10 times the database resources and is running much slower.  What has been your experience replacing client server apps with Java EJB systems? Is this typical or just an application design issue?

John McQuilling
Monday, March 17, 2003

Your EJB app is only 5 to 10 times slower? You should write a book on how to get good performance out of EJB.

TJ Haeser
Monday, March 17, 2003

It's application design issue. But it's very typical for EJB :)

raindog
Monday, March 17, 2003

EJBs are notable for hurting performance.  Especially if they are used for fine-grained classes.

T. Norman
Monday, March 17, 2003

I'd expect poorer performance, but I don't think there should be added consumption of database resources.  If anything, there should be *less* usage of database resources as a result of connection pooling.  So maybe the connection pool is too large, or there are some other application design issues.

T. Norman
Monday, March 17, 2003

"In many respects, this is a microcosm of the problem facing EJB (and all of J2EE, for that matter, but to a much smaller extent). EJB is a specification designed by and for modelers who don't want to deal with the underlying details of how the system is going to work. As a result, we have Container-Managed Persistent entity beans, Container-Managed Transactions, and coarse-grained bean-level synchronization policies that make the techies cringe and run away in outright horror. On the one hand, this is why people can feel so productive with EJB after using code-generative UML tools like Rational Rose or Together/J; on the other hand, this is why EJB systems done that way typically suck and can't scale beyond the developer himself."

Read Ted Neward's review of "Naked Objects, Techies and Modelers" here http://www.neward.net/ted/weblog/index.jsp?date=20030313#1047602905486 for some insights on why the EJB spec just sucks if you actually want to put it to use in production.

Just me (Sir to you)
Monday, March 17, 2003

About the data base performance one of the biggest problems was handling scrolling. With the PB app all the data was sent to the PC and it handled the scrolling.  We found that the browsers can't handle that kind of data so we had to write the data to a temp table and send only next page.  When the user scrolls we do it all over again. Throw in a few updates to fill up the log and the data base is crawlling.

I really like the answer about writing a book LOL.

John McQuilling
Monday, March 17, 2003

Personally I don't have a problem with EJB performance in production. The trouble is most EJB applications are written poorly - there are a lot of traps in ejb design.

I have written a set of quick & dirty proof of concept apps using CMP EJB (on weblogic) with jsp, all java servlet, and asp.net data grid, all talking to one of our existing mysql tables, and found the performance within the same ballpark.

Rhys Keepence
Tuesday, March 18, 2003

"Read Ted Neward's review of "Naked Objects, Techies and Modelers" ..."

I agree absolutely with Neward's proposition. The problem, however, is that many (object) modellers miss out what, IMHO, is a critical step: the transformation of a logical model into a physical model. Just as in data modelling it is necessary to convert the logical model (typically composed of entities, attributes and relationships) into a physical model (tables, columns, indices etc.), so I think it is important to transform a logical object model into a physical (component, implementation, call it what you will...) model for coding.

I consider the purpose of a logical model to be to express the overall structure of a system in a simple, clean, probably top-down, way. An elegant object model is, or at least should, be free of implementation constraints and is checked against the requirements for the system. Any physical projection of that model, however, should be fully aware of the constraints of the implementation technology. This is where the 'techies', bottom-up approaches come in so as to ensure that the implementation is efficient. Just as if you create SQL straight from a logical data model, without consideration of factors such as access paths that are introduced into the physical model, you can easily create a slow solution, so if you generate code straight from a logical class model you are likely to create a very inefficient implementation.

In my last job we had one, very large, logical data model and several physical projections thereof, each targeted at a different database engine or using a different projection of classes to tables and views. The same should hold true for logical object models. One should transform the logical (class) model into a component model targeted at the implementation language / environment / libraries. Code generation should be from the components, _not_ from the logical model classes.

The troubles with this are that the approach is not adequately discussed in the non-academic 'design and program with UML' literature and that far too many UML modelling tools let you generate code straight from their class models. None, that I know of, offer really good support for the transformation of classes to components; as often as not 'reverse engineering' capabilities don't even let you create components, just classes!

As a digression, I also feel that the difference between logical and physical modelling can be used to good effect in XP style programming. There is often a certain hesitance to use XP on large projects because there isn't an obvious place to record overall requirements and architecture. This is a potential nightmare when requirements are imposed by legislation that an end user may not be aware of. XP practices, particularly refactoring, can be used to good avail to create the physical model. "Take my logical model, it tells you (a) important background information and (b) what you must be achieve by the end of the project; go sit with the users and design and build something that works well for them ..."

David Roper
Tuesday, March 18, 2003

EJBs are overkill for 90% of applications.  I would give Hibernate a try, it is a free lightweight O/R framework that is easy to configure and very fast:

http://hibernate.bluemars.net/

Colin Evans
Tuesday, March 18, 2003

Rhys,

You metioned using asp.net's datagrid with EJBs.  Is this a common solution?  How exactly did you implement this? (web services?).  I'm intrigued by the idea of using the best of aspx with j2ee.  Does anyone have more info on this?

Vincent Marquez
Tuesday, March 18, 2003

Sorry, I probably didn't make that clear :)

I have written a page with the same functionality, using 3 different technologies (aspx, all servlet, and jsp + cmp ejb) and under load testing found the performance acceptable for all three.

Rhys Keepence
Tuesday, March 18, 2003

*  Recent Topics

*  Fog Creek Home