"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
