Tp a écrit :
> Hi,
>
> we have to develop a high performance chat based only on HTML and HTTP
> only for a television company. The biggest issue is performance. The
> chat's output window requires one open HTTP connection per client.
> This means, that when you have 3000 people following the chat that the
> server has to be able to handle 3000 simultaneous ie. open HTTP
> connections.
>
> I have read some old benchmark tests. In those Tomcat does not get a
> very good rating compared to other servers like JRun, BEA and others,
> since it does not use NIO or some native methods. I guess I could try
> just to open 3000 threads on my machine which write some output and
> see how it's doing but I guess that does not really tell me anything
> reliable.
Use tools like jmeter to stress test an application. (Of course, do not
run jmeter on same machine as server is running, this would bias the
results) such tool can give you information on server response time
compared to number of simultaneous request.
>
> So I was wondering if anybody can really tell me what Tomcat's (5.5)
> limit is on this? How many simultaneous HTTP connections can Tomcat
> handle and still respond in such a way, that the application stays
> useable. I assume that the machine runs on a Pentium 4 3.2 Ghz with 1
> GB of RAM under linux and that all the file descriptor limits are set
> to the maximum.
>
The capacity of server is mainly dependant on what the webapplication
running inside does. If you implement the chat in a 'get refresh of chat
every 0.5 seconds' way, this mean you'll get 6000 request / second. If
you serve them in, for example, 0.1 sec, that mean you will handle a
mean load of 600 simultaneous requests. This can be reduced by setting
refresh of clients to 2 seconds (your drop to serving 150 simultaneous
requests). Fortunately, the OS does pile the connect request until they
get accepted or discarded by tomcat. So when you finish a request you
start another. Your server could receive 3000 GET at same time, they
just won't be all served immediatly.
If you try to serve 3000 request at same time (assuming by design you
don't 'close' the http channel so you can push data from server to
client), you will need 3000 server threads to do it (and this is true
whatever java server application you are using!). Be it tomcat or not,
this is an heavy load and you are subject on hitting the max thread /
process limit on the OS.
To know the max limit of thread is difficult. Here i get a max of 16375
total system threads. Can be increased with writing to special proc file:
cat /proc/sys/kernel/threads-max
16375
To get an idea of the limit for a given java process, i run the
following simple code:
package test;
public class Test extends Thread{
public void run() {
// do nothing but wait indefinitly
try{
synchronized(this)
{
this.wait();
}
} catch (Exception e) {
System.out.println("Exception in Thread");
e.printStackTrace();
}
}
public static void main (String argv[]) throws Exception{
int threadCount=0;
try{
while(true){
threadCount++;
new Test().start();
}
} catch (Throwable t) {
System.out.println("Got exception at raising
thread number "+threadCount);
t.printStackTrace();
System.exit(0);
}
}
}
Here i get a limit of about 5640 thread
Got exception at raising thread number 5642
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start(Native Method)
at test.Test.main(test.java:21)
Increasing threads-max did not seem to change it.
However, number of threads is not the only factor to take in
consideration, that's why i recommend a stress test of your code to
ensure tomcat can handle the load.
> The second question I have is, that lets assume the limit of a single
> tomcat instance is at 2000 connections, how could I use a cluster and
> loadbalancer to increase the total amount of simultaneous HTTP
> connections of the "Applicaiton" and this really possible? Does
> anybody in here have pratical experience for a live production system,
> which is in use and handles many HTTP connections?
>
Tomcat is supposed to be configurable in clustering environnment. But
that's all i know about :)
> yours,
> Tim
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
