EJB design: Servlet vs EJB architecture
I am wondering, if it is better to use servlets or ejbs as server components to keep rich clients' state.
- Posted by: Juergen Weber
- Posted on: November 07 2004 17:47 EST
So I did a little test, running 20 clients against a Servlet (Commons HTTPClient as client, which maintains Session cookies) and against an EJB.
Data = Hashmap with 20 Strings, 20 Doubles and 20 Dates.
Servlet had one Data in Session, EJB one Data in member variable. Also, EJB method got this Data as input and returned it (call by value). Servlet got this Data serialized (using JDK's ObjectInput/OutputStream) into Base64 and returned it, too.
Using grinder.sourceforge.net I ran 20 clients, each one thread, against WLS 8.1 SP 2, clients and server both running on the same machine, an old 500 MHz Suse 8 Linux machine, Sun JDK 1.4.2, Memory restrained to 32m.
Servlet: 35 TPS (mean)
EJB (transaction-type Bean, trans-attribute Never): 22 TPS (mean)
Can anybody confirm these results for other servers? Why is the EJB performance so bad?
Thanks for your ideas,
I discovered that I had the EJB done suboptimally.
Originally I had home.create() in the test method (within the loop). Now I pulled it out to the setUp() method, and now the TPS numbers doubled.
I have now 66 TPS (mean) for EJB versus 35 TPS (mean) for Servlet.
Sorry for my mistake, but I had thought that only the Context-lookup is expensive.
As a further comparision, I also tried a Jacorb Server that results in 170 TPS (mean) !
I wanted to respond yesterday. But, was stuck with a project headache.
Here are a few articles that caught my attention over a period of time:
And this: (Itsa thread in serverside.com, but i only managed to obtain the google's cached copy of it)
Based on these, I was under the impression that the TPS would
be about the same for both stateful and httpsession methods.
That is not to dis-credit your comparison.
But, in my opinion, storing the state in a stateful session does provide some headaches.(refer to articles)
It would be better to store the state in a StateManager, and then, save it in a HttpSession (for web clients) and StatefulEJB (or something else) in other cases.
This way, it should be easy for you to move the state storing responsibility from HttpSession to Stateful bean and vice versa. Even if that is not a concern for you, it will free your applications from having to interact with a HttpSession or a Stateful session bean (both of which you want to avoid) deep inside your layers.