Overall Performance Diff Between "Raw JSP" and J2EE


General J2EE: Overall Performance Diff Between "Raw JSP" and J2EE

  1. We're doing most of our development using a J2EE code generator (Versata). I can imagine the other end of the Java spectrum might be un-MVC raw JSP pages, that just make a connection, grab data, show it, and quit. Where our J2EE is spread over N tiers (web, app, db, client browser), the JSP is just 2/3 (db, app/web, client).

    In general, what should be the performance difference between a normally architected JSP page and a n-tier J2EE? How much difference should I expect?
  2. hi,

    To be honest, there is no exact quantitative answer for these. To answer your question, you need to question whether you require N-Tier architecture. What is the trade off's you have made by choosing N-Tier ? Possible tradeoff's are scalability, extensibility, easy maintenance, clear separation of concerns, modularity, in built container managed services, possibility of clustering at all layers if the requirements are on higher side.

    Check out this whitepaper and the excel sheet which can be customized for your architecture.


    Bhagvan K
  3. Thanks for the spreadsheet.

    But...in general.. how much of a tradeoff should we expect? e.g., all things being equal, a fully architected J2EE form will be X times slower than a quick and dirty PHP/JSP?
  4. I can't give you exact number since it really depends on your requirements (more importantly on the bottlenecks) . If all your app can be contained in jsp pages and maybe some simple code, then go for it. KISS You should save considerable time in development and deployment, while execution should be optimal (excluding entity caching), but at a loss in maintainability, transaction processing, and potentially scalability.

    <disclaimer> It's been a while since I've developed a full j2ee app, since I haven't found had the requirements for it</disclaimer>



    You don't need to know much to do jsp and a few classes, it chould be faster (I'm supposing you might not be an expert in the specs that compose j2ee).


    No EJBs = less deploiment hassles, no tweeking.


    EJBs do security checks, you avoid potentially network problems for your component interactions which should give you a boost in performance. The only place where you might have problems are at the db level where you might want some caching, but in general if you need caching, you'll look at for a more complex system that can be more easily maintained.


    Proper separation of tiers are easier to maintain as the db tier handles the db, etc...


    Magically, EJBs can rollback a sequence of actions (if they couldn't I don't see their purpose).


    In a well architected distributed environment, services can be executed in the least busy machine of a cluster, improving performance. Entity Bean caching can be useful (I prefer Hibernate), but if you need that performance boost, you probably should have better separation of tiers.


    In general, I prefer simple jsp sites as proof of concepts and prototypes. For DB, I use Hibernate. When I need full transaction support, that's when I consider a full j2ee app. The only problem I see is if your client wants to upgrade and notices that the upgrade costs him more than his original investment.