From: "Juan Pablo Lorandi" <[EMAIL PROTECTED]> To: "'Tom Yang'" <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> Subject: RE: FW: JSP/JavaBean compared with EJB Date: Wed, 26 Feb 2003 02:32:36 -0000
Tom, please fw to JSP-INTEREST if you like...
> > > Hi all: > Thank you all very much for your replies! > I'm currently in the process of deciding "to EJB or not to > EJB" for my new > project. My web page uses JSP to generate dynamic web pages > and it uses > JavaBean to talk to a backend database server to issue all > kinds of SQL > statements such as select/insert/update etc.. I feel this > kind of design > (without using any EJB) will serve the purpose. However, the > potential users > of the Web page are huge. I'm concerned about the > "scalability" problem. My > questions are: > 1) Will my web application run into trouble if the number of > users increases > to a certain point?
Any system has a breaking point. The real question is: how much your system can handle? You should test this, using Apache's JMeter or Microsoft Web Stress App tool.
> > 2) Will I not have the same problem if I use EJB instead?
Yes, but it might not impact as much.
> If > so, I can use a > session bean instead of a JavaBean to issue the same set of > SQL statements.
Yup.
> However, I don't see much of a difference between the two > approaches. For > example, after I have instantiated a session bean in the JSP > web page,
Well, the trick is that if it is a Stateless Session Bean(SLSB), you never instantiate it. You'll have an object pool and objects will be reused. The most harming performance issue with Java today is garbage collection(and it impacts directly on scalability). When a web page finishes using a SLSB, it returns to the pool and will be reused. If it were a JavaBean, it would be derreferenced, and would remain in memory until the gc mechanism kicks in. And when it does, your app freezes for a while. This hurts your performance. It impacts scalability too depending on the load and the freeze time.
In an extreme circumstance, this is what would happen: Current web requests are stalled, and more web requests come in and are queued. Eventually your machine hangs (much like a DOS attack).
This can happen with both EJBs and JSP, but on heavy concurrent load, it's more likely an EJB based server can handle more load, even more when the hardware is more powerful as the cost of using EJBs becomes marginal.
> I > call methods defined in the remote interface to issuing all > kinds of SQL > queries/updates. The methods I call are exactly the same as > those defined in > the JavaBean. The only difference is that one is defined in a > JavaBean while > the other is defined in a session bean. So if I make this > change and I can > say "I am now using EJB", will that solve my problem of > "scalability" if I > have any? As I said above, I am very concerned about my web > application > running into trouble when the number of users increases to a > certain point. > Will the design without using EJB inherently be vulnerable to > this trouble?
All designs are inherently vulnerable to this trouble. The idea is that you cluster machines to accommodate for increased load.
> Will the design using EJB (such as session bean) be immune to > this trouble > or at least be easier to deal with this trouble?
I'd think overall EJB makes it easier. How easy? Is it really worth it? It depends on each project. How many machines will you be placing in the web cluster? How will you balance load? What's your expected load(concurrent users)? How many concurrent web requests your machines can handle? How does concurrency slow down single web request handling performance? How much?
> Could > someone please give > some specific scenarios to help me understand the difference > between the > two? > 3) It is said that "EJB design is N-Tired and N-Tiers allow you to > redistribute load more efficiently". In my case, how do I > re-distribute the > load if needed? I can put the database server on a different > machine than > the one running the EJB application server to distribute the > load, but the > same thing can be done with the JSP/JavaBean (with EJB) > design, i.e., I can > put the database server on a different machine than the one > running the > servlet engine such as TomCat.
WM = WebMachine. EM = EJBMachine. DM = Database Machine.
Tomcat Cluster:
WM ----+-----DM WM ----| WM ----| WM ----| WM ----| WM ----| WM ----|
This is known as "scaling up". EJB Cluster:
WM-----+----EM--+ WM-----| | DM WM-----| | WM-----+----EM--+
This is known as "scaling out". Since most of the computing time of the WM are used in sending dynamic HTML out, one single EM machine can handle more than one WM, so you use the hardware more efficiently.
Scaling out works where the cost of network traffic is really low, like a Gigabit Ethernet, but hopefully it'll give you an idea of how you can scale differently by having tiers.
> I know EJB has lots of > advantages. But I may > not need them in this project. The "scalability" problem is > really what will > determine whether I should "to EJB or not to EJB". Could > someone please give > me some advice? Thanks in advance! > > Tom
_________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
=========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant archives, FAQs and Forums on JSPs can be found at:
http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com