EJB Performance - about Overheads

Any level of abstraction is going to increase the performance cost of the systems. But you know this already. If you have a look at Ed Roman's 'Mastering EJB' book, there are some excellent facts about the EJB 'value proposition' that may be useful.

It is important for your client to realise that performance and scalability are not the same thing. The metaphor I like to use is that of a 1/4 mile race between a Porsche and a Dump Truck. Initially, the Porsche will always win, probably before the dump truck has really even got started. BUT, dump 100 tonnes of dirt on the vehicles and try it again. The dump truck will perform in much the same way as it always has, but the Porsche will probably be destroyed. Just hope you aren't in there at the time! As someone on Slashdot said - 'the thing with EJB is that it is consistently slow' - performance doesn't really degrade terribly as it scales.

I think there may be value in trying the two models proposed and measuring the performance and scalbility. without such a test, it is hard to be objective. Model a typical transaction of the system and implement both strategies, paying attention to how long it takes to develop! (And use container manager persistence to really speed the EJB development). Then do some load and stress testing. This way you will have a clear definition of the developmental, performance and scalability tradeofs.

As an aside, there are some patterns that do not use the full Entity Bean stack - using Stateless Session Beans can provide some of the scalability and transactional benefits of EJB without incurring the extra overhead of an Entity Bean solution. These are pretty controversial, I admit, but I have used them to great effect in certain situations.

Posted in: Programming