LUCIO PICOLLI wrote:
>
> I am concerned that the scalabile limit of a servlet is the number of
> active threads. The recent JVM perfromance article
> (http://www.javaworld.com/javaworld/jw-03-1999/jw-03-volanomark.html)
> indicates that the performance of the VM decreases with the number of
> threads. If this is the case then surely the logical step is to have
> mulitple JVM processes running a seperate servlet instance. How do you
> guys get large through put with a single instance of a servlet?
>
You are correct in observing that increasing the number of simultaneous
threads causes an increase in the time it takes to handle a particular
request. However, the overall throughput (number of requests handled per unit
time) generally increases up to a point that depends on the hardware/software
combination's limits.
In general, if your requests are CPU bound, adding a second JVM on the same
server is not going to help ... you are just adding OS overhead to switch back
and forth between the JVM processes. It would help, however, if you are
running on a multiple CPU server, and have spare CPU time capacity on a second
(or third ...) processor. All of this assumes, of course, that you have
enough memory to keep everything important resident.
Don't assume that the separate JVM instances need to run on the same server
(or even the same server as the web server). The capability to spread out
these JVMs across servers is already present in many servlet engines, and lets
you deal with scalability problems where request processing is the bottleneck
pretty gracefully.
One other thing to keep in mind about servlets: the "simultaneous requests"
counts we are talking about here are the number of users who are actually
hitting your server at the same time, not the number of people who are looking
at an HTML page that was generated by your servlet. This is one place where
the "stateless" nature of HTTP actually helps instead of hinders. The only
server impact of a user "in between" requests is the memory overhead for
storing any session data you are maintaining. If the memory requirements are
reasonable, you can support very large numbers of simultaneous users on even
fairly modest servers, as long as the simultaneous requests count is not too
high. And you are even starting to see solutions that deal with the memory
issue, by swapping out sessions that have been inactive for a specified period
of time, and then swapping them back in on the next request.
>
> If am wrong then kindly correct me but the scalability of servlets seem
> to be rather limited.
>
The issues around maximizing performance in multi-user systems go back to at
least the 1960s (Y2K compliant date :-) era timesharing systems, and the
principles for creating scalable server solutions have not really changed much
-- other than getting substantially cheaper. There's nothing in the Servlet
API spec that prevents utilizing these principles -- in fact, the API design
encourages servlet engine providers to offer these kinds of capabilities. The
nice thing about it is that this is transparent to the servlet developer --
your servlet can be designed and written once, and you can pick the deployment
platform that meets your performance requirements, and even change your mind
if you are wrong, without impacing your application code.
>
> -lucio
>
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
