Hello Oleg,
Makes perfect sense. HttpClient allows only two concurrent connections to the same host per default as required by the HTTP spec. Therefore, those two threads that manage to lease a connection from the pool first execute faster than those that stay blocked waiting for a connection to free up.
True. There is a RFC stating than no more than 2 concurrent connections are allowed. That's fine. However our problem is this: if we change the sleep time in the example: http://www.systemdatarecorder.org/ClientMultiThreadedExecution.java /* ****************************************************************** */ long timeLapse = cTime - pTime; System.out.println(id + " - get executed. Response time:" + timeLapse ); // get the response body as an array of bytes HttpEntity entity = response.getEntity(); if (entity != null) { byte[] bytes = EntityUtils.toByteArray(entity); System.out.println(id + " - " + bytes.length + " bytes read"); } sleep(30000); ^^^^^^^^^^^^^ /* ****************************************************************** */ more than 30sec, the response times is 5 smaller than in other cases. Example: running the previous code example with only 2 HTTP requests to avoid the RFC confusion. 1). Sleep time 5s 1 - get executed. Response time:173 2 - get executed. Response time:170 2 - 8005 bytes read 1 - 8005 bytes read <this is ok since the JVM is not warmed up, the methods are not yet compiled> 1 - get executed. Response time:11 2 - get executed. Response time:11 1 - 8005 bytes read 2 - 8005 bytes read 2 - get executed. Response time:11 1 - get executed. Response time:11 2 - 8005 bytes read 1 - 8005 bytes read So our response time is 11ms. Seems consistent 10-11ms. 2). Sleep time 35s 2 - get executed. Response time:130 1 - get executed. Response time:131 2 - 8005 bytes read 1 - 8005 bytes read 2 - get executed. Response time:3 1 - get executed. Response time:3 2 - 8005 bytes read 1 - 8005 bytes read 2 - get executed. Response time:2 1 - get executed. Response time:2 2 - 8005 bytes read 1 - 8005 bytes read Now we started to see a different thing. Response times went down 5 times since previous run. Why is that ? So our problem seems to be dependant on sleep time between runs. If it is > 30s the response times seem to align with the reality. We tested the code from this example: Client Linux --- Solaris HTTP Server Usually it takes 1 or 2ms for httping or a simple wget or curl. Any ideas ? Many thanks for help. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
