Thank you Craig for the concise speedy response. I would like to rephrase
my second question so that you or anyone else will have a better
understanding of what I am looking for.
1.) what would be the performance difference for sending all request
through a single servlet and having that servlet forward all of the request
to Java beans (using Java reflection) to handle the business logic versus
having a specialized servlet for each business logic unit?
i.e.
CASE 1:
having a simplesingle servlet that would handle the requests
for both a news page and a stock page
CASE 2: vs.
having two servlets to handle each request. Such as having
a newsServlet and a stockServlet.
NOTE:
Our scenario would have to handle close to a hundred pages
and there COULD be over a thousand hits simultaneously to any of these
pages. For instance there could be 10 people accessing the new page and 10
people accessing the stocks page simultaneously. Which in the first case
would cause 20 request to one servlet as opposed to 10 request to each
servlet as in the second case.
What would be the cost of servlet performance by implementing CASE 1
as opposed to CASE 2.
Thank you for any help you might provide,
Brian
-----Original Message-----
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 02, 2000 12:37 PM
To: [EMAIL PROTECTED]
Subject: Re: Servlet Performance
"Suggs, S. Brian" wrote:
> Hi all,
> Does anyone know if there is a limit on the number of concurrent
> threads a servlet can handle?
The only thread limits will be those imposed by your JVM or operating
system.
The Volano benchmark (www.volano.com) has some interesting test results on
the
number of threads that various JVM/OS combinations can support -- since
Volano's primary application is a chat server, that is a very important
factor
for them. Thousands of simultaneous threads is not uncommon.
> Also, what would be the performance
> difference for a single servlet handling n simultaneous request as opposed
> to n servlets handling 1 request each?
You get a memory space win (depending on how big your servlet class's
instance
variables are, and how big "n" is) if you use a single instance. Assuming
all
other things are equal (i.e. equivalent locking of shared resources), there
won't be any other significant difference in the ideal world.
But, in the "multiple servlet instances" case, the reality is that "n" is
not
typically allowed to scale in an unbounded fashion. When you implement the
SingleThreadModel interface (which tells the servlet container to only allow
one request per servlet instance at a time), what usually happens is that
the
container sets up a pool of instances of your servlet -- otherwise, you'd be
single threading them through a single instance and that would be very bad
for
response time. The key point is that the upper limit on the pool size (in
other words, the upper limit on the number of requests that are really
handled
simultaneously) is usually bounded to some configured number -- if you have
more simultaneous requests than that present in your container, some of them
are going to have to wait for an available instance. This does not happen
in
the "single instance" case.
And this all glosses over the fact that having multiple instances does *not*
solve all your multithread concerns in the first place. For example, it is
still very easy to have multiple requests active on the same session -- so
you
have to be aware of locking issues anyway.
The bottom line -- I strongly recommend that you design your servlets to
operate in a "single instance" environment. Most of the work involved is as
simple as not using servlet instance variables to store per-request state
information.
>
> Regards,
>
> S. Brian Suggs
>
Craig McClanahan
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
