On 03/21/2012 08:37 PM, ??? wrote:
I do a test for concurrence of resin, and my conclusion is right? Tks for
answer.
Test the resin in the number of concurrent, even up to 5128
Test environment:
the server side: OS: I machine, 32-bit os, 3g memory, 1.8g dual-core CPU
resin:-Xmx1400m-Xss64k (set to minimum, in order to occupy as little
memory)
client: the loop to create 7000 threads, each cycle access resin100
Test results: resin console to see the number of threads in the Thread pool,
up to 5128;
Summary: If os, memory, cpu is ideal, on the resin itself, the maximum
number of concurrent 5k more than;
Problem: the error rate is high (7000 threads, each of 100 req thread pool
maximum value of 5128, the error rate of 42%; (1000 threads, each 100 req
thread pool max 388, the error rate of 15% ); In summary, it should be said
5k multiple concurrent ideal state, in real environment, it may be a few
hundred more than almost?
Well, that kind of measurement is a bit tricky.
1. You do want to distinguish between connection errors and other kinds
of request errors. If there's a large spike of connections (like in your
test case), refusing connections can be a good thing, to reduce the
number of threads in the JDK. If you start getting internal errors, it's
a problem.
2. Spikes are different from steady-state load. We just tested Resin for
high loads and had 100,000 req/sec and 10,000 connections/sec (1:10
keepalive.) Since Resin does increase the thread pool and accept pool
for the connections, it's possible to see a higher rate after a bit of
warmup.
That warmup would be even more true for a full application that has
caches, etc. that need filling.
3. active vs keepalive vs async/comet vs websocket makes "concurrent
connections" count more complicated. 5000 active threads is a lot and if
those were actually doing CPU calculations, it would be inefficient,
since you only have 8-16 (or whatever) cores.
Keepalive connections or an async/comet idle thread or an idle websocket
connection are also concurrent connections, but they're not active most
of the time. That total tcp-socket count matters, too. And you might
want that number to be much higher, like 10,000 or 25,000 or more (for
example a chat or twitter server.)
And even the active threads can be blocking, for example waiting on
databases. In a perfect world, you'd want about the same number of
CPU-active threads as you have cores.
Your test is a good start, and an important measurement. I'm just giving
a few suggestions of related issues to also think about.
-- Scott
My test code is as follows:
public class Test1 {
public static int success = 0;
public static int fail = 0;
public static int reject = 0;
public static void main(String[] args) throws Exception {
long a = System.currentTimeMillis();
ThreadDemo[] td = new ThreadDemo[7000];
for(int i=0;i<td.length;i++){
td[i] = new ThreadDemo(i,a);
}
for(int i=0;i<td.length;i++){
td[i].start();
}
}
public static synchronized void setValue(int s,int f,int r){
success+=s;
fail+=f;
reject+=r;
}
public static class ThreadDemo extends Thread {
private int id = 0;
private long s = 0;
public ThreadDemo(int id,long s){
this.id=id;
this.s=s;
}
@Override
public void run() {
int success = 0;
int request_fail = 0;
int request_reject = 0;
URL url;
for (int i = 0; i< 100; i++) {
try {
url = new URL("http://ip:8080/Project1/test.jsp";);
InputStream is = url.openStream();
byte[] b = new byte[100];
StringBuffer sb = new StringBuffer();
while(is.read(b)!=-1){
String ss = new String(b,"utf-8");
if(!"".equals(ss.trim()))
sb.append(ss.trim());
}
is.close();
success++;
} catch (ConnectException e) {
request_fail++;
}catch(SocketException ee){
request_reject++;
}catch(Exception e){
e.printStackTrace();
}
}
Test1.setValue(success,request_fail,request_reject);
System.out.println("request --" + id + "-- url end.take "
+ (System.currentTimeMillis() - s) + "ms
success="+Test1.success+" fail="+Test1.fail+"
request_reject="+Test1.reject);
}
}
}
_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
