Sandeep Tikoo wrote:
> Hi All,
>
> I am using BEA Weblogic 4.5.1. Does WebLogic (or for that matter any
> Servlet supporting webServer) impose any limitations on the number of
> concurrent client requests that a servlet can handel. The application that
> we are working on is an Internet application and as a result such issues
> are important to us.
I don't know about WebLogic 4.5.1 in particular, but one of the ultimate
limits on how many servlet requests an engine can process is the maximum
number of threads your JVM will support on your OS platform. This value
varies widely -- the Volano report (don't remember the URL offhand) publishes
benchmarks for this on a wide variety of platform and JVM combinations.
Of course, a heavily used server can run out of other resources (CPU speed,
disk access speed, memory) as well, so this might not be the first limit you
run into.
Your app server may also offer ways to configure maximum limits -- check the
app server docs for more info.
>
> if the webserver does not impose any restrictions on the no. of concurrent
> requests a servlet can handel then in case the number of client threads on
> a servlet at an instance of time is very high would that result in a slower
> response time? In that case is there a work around for the problem?
>
There is no pat answer to what happens to performance -- it is as much
dependent on your application as anything else. However, many interactive
application systems exhibit a pattern similar to the following:
* Single user access provides some particular response time rate.
* As simultaneous users are added, response time stays relatively
constant, or increases fairly slowly. This happens because you
have not yet hit any performance bottlenecks in your server.
* At some point, adding new users causes response time to start
climbing much more rapidly. This happens when you hit some
limit in the current architecture. The purpose of benchmarking here
is to figure out which limit you hit, so you know what to change.
The solutions are the usual ones:
* Throw hardware at it (if you run out of CPU speed or memory
first, this can be much cheaper than investing the programming
hours to change your architecture).
* Distribute the processing across multiple servers. If you are
running your DBMS on the same machine, for example, try it
running on a separate machine. You incur more network overhead
but you are buying back performance capacity on the servlet engine.
App servers may let you install your servlets on more than one
server, splitting the user load between them.
* Benchmark your app to identify the hot spots, and optimize the
performance of those spots. For many interactive apps, the 80/20
rule still applies -- 80% of the time is spent in 20% of the code, so
you don't usually have to look at all of it.
* Artificially limit the number of simultaneous users. If you are in an
uncontrolled environment (like an Internet based application), use
your app server's facilities (or code in your own apps) to limit how
many users are allowed to access the app at once.
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
