130.000 HTTP Sessions With -Xmx512m--A Scalability PoC

Can Stateful Applications Scale?

Sometimes the question is answered with "No" (without any testing), and trivial, but stateless, enterprise applications for a few users are built with a significant overhead.

In the following screencast, I created with the pace of 500 HTTP sessions per second as many HTTP sessions as only possible in a trivial PoC. A HTTP session consists of a SessionScoped backing bean and a Stateful Session Bean with three attributes. A stateful Boundary in addition to a SessionScoped backing bean in this context does not make any sense, but wastes more memory and therefore shortens the screencast :-)

[See also an in-depth discussion in the "Real World Java EE Patterns--Rethinking Best Practices" book (Second Iteration, "Green Book"), page 50, chapter "The Extended Mode and Concurrency"], page 91 in chapter "Gateway", and page 429 in chapter "The Essential Complexity of Domain-Driven Designs".

See also other screencasts at: http://tv.adam-bien.com or subscribe to http://www.youtube.com/user/bienadam.

See you at Java EE Workshops at MUC Airport (March 25th-28th)!

Comments:

Thanks for this - it was a very clear and concise example of how to use JMeter and Lightfish to drive and monitor a simple Glassfish app. I was able to follow all the steps and get it all working.

Posted by Barton Hammond on December 18, 2012 at 03:44 AM CET #

Thanks for this. I am going to get your green book and have a browse. In the meantime, have a look at http://goo.gl/i4gW . Its the one study that sort of changed the way I thought about scalability.

Posted by Suhail Manzoor on December 18, 2012 at 02:17 PM CET #

Adam, try to press Enter in NetBeans after "{". For example:
"public String message() {" and then ENTER. And you will get one second more to code :)

Posted by Wojtek on December 18, 2012 at 03:53 PM CET #

While Stateful Session Beans do not create a huge performance penalty, I think the biggest problem with using them is, that many developers do not understand "scope" and the lifecycle of objects.

So this is a great feature, if you know what you are doing, but I don't want to be the one searching for memory leaks in an object graph referenced from a stateful bean, just because someone did not understand, that adding multiple 100.000 element search results to the stateful bean, perhaps is not such a good idea, if there is no concept on when they are removed again.

For most starting/average developers not using stateful beans is probably better (imho). And they will use them, if anybody else is. And they won't notice the difference between a "trivial" application and a problem.

Posted by Niklas Mehner on December 18, 2012 at 06:39 PM CET #

@Niklas,

I would say: you are right. You can code most of the trivial applications in a stateless way without any overhead. The more challenging and interactive the business logic gets, the easier the stateful way becomes.

However--it is rarely argued that way. Most discussions circle around scalability, what is not that important for business applications with a limited amount of users.

And: Motivated developers are smarter, than you may assume :-) (9-5PMers not considered here :-))

adam

Posted by Adam Bien on December 18, 2012 at 10:12 PM CET #