> 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.
My requests are blocking the calling thread not due to CPU resource but
due to remote method inovocations.
> 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.
I was not aware of that, i'll check out the docs.
> 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.
Your points are understood but my issue has not been addressed. I'll
attempt to rephrase my concerns.
-JVM performance is limited by the number of concurrent threads.
-A servlet instance runs in a single JVM.
-Hence a servlet's performance is limited by the number of concurrent
threads
-Hence a servlet has a maximum number of concurrent users.
-There seems no mechanism for having multiple instances of the same
servlet.
Now for a servlet invocation that can block the calling thread ( ie a
CORBA method call ) there is a real possiblity that the number of
concurrent threads can be large. In which case the JVM peformance will
drop, increasing the executation time of each thread.
Am i just paranoid or is there a real problem here? Does this concurrent
usuage problem occur in normal CGI? If so what is the solution? I suspect
that the problem does not occur in CGI because the number of instances of
the CGI is only limited by the resource of the box.
>
> >
> > 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.
>
I am not critical of the servlet API, or even java. I just don't want to
be force to drive *all* particular servlet requests through one servlet
instance. I would like to have multiple servlet instances and load
balance across them. Whether this is a servlet issue or servlet engine
issue i am unsure.
Netherless i would like to hear from anyone implementing servlet's with
large concurrent users.
-lucio piccoli
___________________________________________________________________________
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
