On 03/21/2012 08:37 PM, ??? wrote:
I do a test for concurrence of resin, and my conclusion is right? Tks for

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
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++){


     public static  synchronized void setValue(int s,int f,int r){

     public static class ThreadDemo extends Thread {
         private int id = 0;
         private long s = 0;
         public ThreadDemo(int id,long s){

         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();
                         String ss = new String(b,"utf-8");
                 } catch (ConnectException e) {
                 }catch(SocketException ee){
                 }catch(Exception e){
             System.out.println("request  --" + id + "--  url end.take "
                     + (System.currentTimeMillis() - s) + "ms
success="+Test1.success+" fail="+Test1.fail+"


resin-interest mailing list

resin-interest mailing list

Reply via email to