Discussions

Performance and scalability: EJB Performance

  1. EJB Performance (2 messages)

    Hello,

      I have been told, at an account where I am working, "if you can prove to me that using EJBs does not introduce a performance hit compared with not using EJBs we will use them."

      I have explained to their chief architect the positive effects of using EJB's, such as:
     - free transactional control via the container
     - ability to concentrate on business logic and not on infrastructure
     - do not have to worry about scalability (will be handled via the container)
     - etc.

      Logic dictates that any time there are indirections introduced into a process more time is required to complete the process. But, how do I convince them that the overhead introduced by EJB's is so low (if that is really the case) that it does not warrant writing/rolling their own code to handle the free stuff from a container.

      A pointed statement that I heard is "We would rather write our own code to access the database (via JDBC) and handle the demarcation of transactions (and rollbacks) instead of using EJBs as they introduce too much overhead."

      How do I response to these statements and questions? I have looked for facts/resource that would support my view that EJB overhead is small compared to the gains.

      Any and all help would be appreciated.

    Douglas WF Acheson

    dwfa@yahoo.com

    Threaded Messages (2)

  2. EJB Performance[ Go to top ]

    Yes, there is overhead. 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.

    I think that it is important to realise that this is not some newfangled idea, but the logical progression of technologies - for quite a long time, component based development has been the way to achieve scalable, transactional based systems. Corba, COM/MTS and COM+, EJB are all based on essentially the same model.

    Roger Sessions (http://www.objectwatch.com) has some interesting comparisons of EJB and COM+ that highlight the paradigm.

    I agree with what you have stated - judicious of EJB gives you a whole lot of stuff for free. The cost/benfit analysis is essentially a matter of performance loss over development expense.


    Interestingly, this argument:
    "We would rather write our own code to access the database (via JDBC) and handle the demarcation of transactions (and rollbacks) instead of using EJBs as they introduce too much overhead."

    can be extended to nearly every facet of development, it is just a matter of knowing when to stop...technically, using JDBC is a performance hit and it might be better to talk to the database on a native level. Then again, why use Java? Writing in Assembly is definitely going to increase performance...

      
  3. EJB Performance[ Go to top ]

      The most valuable benefit a client will get from adopting EJB is that the application will contain fewer defect and fewer man-made overhead lurking in the developed code.
      What is a man-made overhead? Thinking that a programmer using many SQL code to accomplish a certain function. Actually, he will find it so simple with EJB, even just a line of code will do all the necessary things on database, that he probably will complain why he didn't know this technology until that time.
      All I want to say is that EJB really simplified our programming, removing many latent bugs with solid SQL codes.
    This is the most important factor that a client mush consider.