Sunday March 16, 2008 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 :-)
Gesendet von admin [Java EE 5 Architectures] ( March 16, 2008 12:00 PM ) Permalink | Kommentare [11]
Senden Sie einen Kommentar:
This might be a bit off-topic, but I just bought myself a new development machine with 8GB of memory and installed Ubuntu 7.10 64bit. The difference between 2GB and 8GB is huge, with all of the languages I use. It's like the first time you develop with a large monitor, it broadens your horizons.
Gesendet von Mikael Gueck am March 16, 2008 at 02:09 PM CET #
Hi Mikael,
I've 4GB for development with Vista - so actually 2GB :-). It needs already 1GB to show the desktop...
thanks for the comment,
adam
Gesendet von Adam Bien am March 16, 2008 at 03:34 PM CET #
Wotif.com website has plenty of architectural and design issues I wouldn't be believing everything Gluck feeds the press about it's "wonderful" architecture under glassfish. In fact I know for certain that many, if not most of the senior devs would sooner have a single POJO architecture.
Gesendet von former wotif dev am March 17, 2008 at 08:05 AM CET #
s/single/simple/
Gesendet von me again am March 17, 2008 at 08:06 AM CET #
Hi Former Wotif Dev,
for clearification. I do know nothing about wotif's architecture - I heard only about the memory consumption - and it amazed me.
EJB 3 are POJOs :-),
regards,
adam
Gesendet von Adam Bien am March 17, 2008 at 09:20 AM CET #
Hmm, ... interesting, ... and not.
Few, very few, online applications of today, are gonna care about a little bit less or more memory consumption. These are micro-optimizations. If you have the need to scale bigtime, I think you will always have to have a plan to scale out, with a lot of parallel machines.
A technology like Rails, which is dead-slow when compared to much other technology stacks, can scale just fine. If you scale out.
So, I say, choose the development model (EJB, POJO, whatever) you feel most comfortable delivering in, and use that.
Gesendet von Tech Per am March 19, 2008 at 01:31 PM CET #
Hi "Tech Per",
First of all "Rails" just does not scale at all ;)
No I'm just kidding.
I disagree, that memory consumption optimization is just "micro-optimization".
There are various reasons why an application might not scale and one of them could be that it's scalability is limited by the memory consumption (and not by cpu) per user.
Of course you can try to "scale out" and use more servers, but we all probably know that this is usually neither easy nor do most applications scale linearly with the number of server nodes.
It's also not free, because more servers cost more money.
If you can cram 1000 Users on one Server instead of 500, because you optimized the memory consumption per user, you only need half the number of the servers which means less cost.
Regards,
Markus
Gesendet von Markus Kohler am March 19, 2008 at 04:53 PM CET #
Memory usage is no problem as long as you really get traffic onto the system. Let us assume that POJOs only need half the memory a full stack EJB3-container would need (I assume the factory is more 1:10) then this means that the garbage collection will be so busy that you will notice it in terms of overall-performance. Okay, a system does not only include POJOs / Session Beans, of course. But bare in mind that comparisons like this one are higliy academical as long as they were not monitored in productive / trafficed systems.
Just my 0,02$, Georgi
Gesendet von Georgi am March 19, 2008 at 05:00 PM CET #
Hi all,
Just to be clear.
I don't really expect a huge difference in memory *per user* for EJB's versus POJO's in case both do support the same features.
But you just know "nothing" untis you have measured it.
I agree that the initial memory consumption is usually not that important, also I've seen cases were J2EE applications would need more heap then 32 bit Windows could handle and development is ( I guess) still not done on 64 bit machines.
My offer still stands. Give me heap dumps and I will deliver a memory consumption analysis :)
In the past you could have said that there are no good tools for memory consumption analysis. Those of you who have tried JHAT on a big J2EE application heap dump, know what I mean. :]
No more excuses guys, because one of the best heap dump analysis tools (shameless plug ;) ) will be open source soon (
http://www.eclipse.org/mat/) and is already free today.
Regards,
Markus Kohler
Gesendet von Markus Kohler am March 19, 2008 at 05:21 PM CET #
@Markus: Of course, memory consumption *can* be important. But consider this: What i propose is, that other things might be more important, when considering project development.
A, maybe somewhat theoretical example, could be, that you chose EJB2 over some other technologi FooBar, because you thought it to be more memory efficient. Sadly, EJB2 turned out to be a pain to deliver functionality in, with the net effect, that the product never got to be popular enough, that it ever needed to scale bigtime :-)
So, what I propose, is to focus on choosing productive frameworks, and not so much on smaller optimizations/performance considerations. It is not just Rails, but also stuff like Grails, for instance.
Gesendet von Tech Per am March 20, 2008 at 08:31 PM CET #
Hi All,
thank you all for the comments. Productivity is not everything - maintenance and monitoring becomes more and more important. What I see in my projects is the separation between development and operations. So the developers just doesn't care and deploys something that runs...and causes huge costs in the future. I never had a problem with memory consumption, except we got some restrictions from the operations. Then we were able to run the whole enterprise EJB 2 app on -Xmx256m...
EJB 3 on turn is even able to minimize lines of code - I will post about this in one of the future posts (and I'm already curious about the comments :-))
Thanks again for the comments,
adam
Gesendet von Adam Bien am March 22, 2008 at 06:47 PM CET #