On Mon, 2009-12-28 at 14:44 +0200, Stefan Parvu wrote: > 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 >
what on earth is Solaris HTTP Server? > Usually it takes 1 or 2ms for httping or a simple wget or curl. > > Any ideas ? > That is because wget and the likes usually do not re-use connections. Some web servers can not handle persistent connections well, so opening a new connection may turn out to be faster than re-using a persistent connection. Turn off the stale connection check and use context / wire logging to see where exactly Httpclient gets blocked. http://hc.apache.org/httpcomponents-client/logging.html You may also want to search the archives for questions on performance tuning. Oleg > Many thanks for help. > > Stefan > > --------------------------------------------------------------------- > 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]
