On Fri, 10 May 2002, David Cherryhomes wrote:
> Date: Fri, 10 May 2002 15:14:34 -0700 (PDT)
> From: David Cherryhomes <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: RE: Scalability question
>
> I'm sorry, maybe I was unclear. I am not challenging the
> usefulness of Struts, I am well aware of the vast amount of
> functionality that the framework encompasses. I am currently
> using Struts as a core part of the MVC approach in my enterprise
> application. My question is about the scalability of Struts
> Action classes.
>
> It is my understanding that a Servlet engine will create new
> instances/threads of a Servlet as needed (similar to stateless
> session beans), and hence is very scalable for multiple
> concurrent requests.
This is true only if your servlet implements the SingleThreadModel (STM)
interface. If it doesn't, a single instance of your servlet is allocated
and is shared by all concurrent requests. The Struts controller servlet
is an example of this (it is not an STM servlet) -- there is one and only
one instance of this servlet for your webapp.
> My understanding is that an Action class,
> on the other hand, is stored as an instance variable.
The set of Action instances that have been created are stored in a servlet
instance variable, but they are reused on multiple requests for the same
action. In fact, Struts makes a similar guarantee about Action instances
to what the servlet container promises about non-STM servlets -- there
will be at most one occurrence of any given Action implementation class.
> The
> question is this: if I have a class that performs a massive
> amount of business processes (inclusive of attaching to multiple
> EJB's), will the multiple concurrent requests end up queued in a
> wait status until each one is finished processing, or is there a
> multiple instance/thread approach to Action classes (similar to
> a Servlet engine with Servlets)?
>
Action instances have exactly the same thread processing characteristics
as non-STM servlets - the single instance is utilized by multiple requests
(on different threads) simultaneously. This has two important
implications:
* You (and Struts) don't have to worry about pooling Action instances -
the same one is reused continuously, with no locking or allocation
overhead.
* You must program your Action instances in a thread-safe manner.
The most important rule is to not store any per-request state
information in instance variables in the Action class.
> The enterprise application I'm working on isn't for some
> website, but a truly web-deployed enterprise app which must
> scale to thousands of concurrent users with millions of records
> in the DB. Thus, performance is a HUGE concern (e.g., a wait of
> 500 miliseconds is about the max permitted).
As long as the servlet container you're running on can support the number
of simultaneous requests you need, you're going to find that Struts is
basically irrelevant to scalability on the business logic side of things.
You will definitely have to configure your EJB server to support adequate
pools of bean instances, because they do act like STM servlets.
In the presentation layer, using Struts (or more precisely, using the
Struts tag libraries) can have a performance and response time impact,
depending on the quality of the code generated by the JSP page compiler in
your servlet container. As long as you don't exceed the simultaneous
response capabilities of your container, this is primarily an issue of CPU
time in the web tier servers.
>
> Thanks
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
