> 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.
Juan Pablo Lorandi <[EMAIL PROTECTED]>
===========================================================================
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
