EJB 3 and Memory Consumption Myths or Is it worth to use POJOs instead of EJB 3 in terms of memory? 📎
The last time I'm often asked about the usage Stateless Session Beans (EJB 3) regarding memory consumption and comparing them to POJOs. The nice Markus Kohler's comment for my recent post:
"Is it worth to use POJOs instead of EJB 3 in terms of performance? (with results, source and load scripts)" made me curious - and I started some evaluation. Some facts:
- Yes, it is true that an EJB 3 consumes some more memory comparing it to a standalone POJO. The decoration process (often with dynamic proxies), consumes times more memory, than a one instance of a class. However you will need the same aspects in POJO scenario as well. At least transactions, concurrency and remoting are often required. Then it wouldn't be much difference between the both.
- Under load the application server tries to create as less Stateless Session Beans (SLSB) as possible. You will only get several instances of one SLSB, in case the requests will arrive exact in the same time. Achieving the same effect with POJOs in WebContainer isn't an easy task. Most of the application server (especially commercial ones, or glassfish) allow you fine graine runtime configuration (Min/Max Pool Size) and especially minimize the scalability (which is really important to avoid Denial Of Service attacks)....
- In a pragmatic architecture you wouldn't have many SLSB. In general case you will get some facades - which wouldn't cascade in general. Even for huge application you will only in rare case get more then 30 SLSBs. In this context the additional consumption just doesn't matter.
- Yes, there is an initial overhead between plain WebContainer and and full-stack applicationserver. But in the practice it just doesn't matter. I run this weblog (not a huge traffic: 3500 visits a day and 20k hits), http://greenfire.dev.java.net (here happens a lot), http://underworld.dev.java.net (this one is heavy) and some Java EE 5 applications like http://www.adam-bien.com/tdb ....with -Xmx786m setting. I attached to Glassfish the JConsole and found out, that it actually only needs around 400MB RAM. My "commodity" box has 4GB built-in so I just don't care...
- It is worth to use an application-server, not just because of development, but especially production. An application server offers you sophisticated monitoring and management capabilities (they have to exists since J2EE 1.4, because of JSR-77). Glassfish goes beyond that and offers you CallFlow.
- Remember, Plain Old WebContainers are dead :-).
- The popular Wotif page runs on Glassfish with 8GB RAM server. I'm not really sure, whether it would be possible to minimize the memory consumption with a plain WebContainer - and what costs could be saved with such an action in this case.
- 1 GB RAM costs on amazon.com around 20 $ :-).
- The tooling for EJB 3 and JPA and integration with an application server are just great (just check out Netbeans 6.0/6.1). The mix of Dependency Injection and Convention Over Configuration saves lot of code. This is good for maintainability and a topic for one of the next posts :-)