Mailing-List: contact httpclient-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient Project" <httpclient-dev@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of odi@odi.ch designates
 81.7.230.227 as permitted sender)
Message-ID: <4304543D.6000906@odi.ch>
Date: Thu, 18 Aug 2005 11:26:21 +0200
From: =?ISO-8859-1?Q?Ortwin_Gl=FCck?= <odi@odi.ch>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: HttpClient Project <httpclient-dev@jakarta.apache.org>
Subject: Re: [HttpCommon] NIO is one huge disappointment
References: <1124308127.2993.61.camel@localhost.localdomain>
 <430399A3.5060005@tibco.com> <1124314853.2993.83.camel@localhost.localdomain>
 <78f7873e050817145230da8787@mail.gmail.com> <43044128.4010405@odi.ch>
 <20050818081835.GA16052@uml24.umlhosting.ch> <43044926.4000200@odi.ch>
 <20050818084907.GA16097@uml24.umlhosting.ch>
In-Reply-To: <20050818084907.GA16097@uml24.umlhosting.ch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Oleg Kalnichevski wrote:
> On Thu, Aug 18, 2005 at 10:39:02AM +0200, Ortwin Gl?ck wrote:
> 
>>
>>Oleg Kalnichevski wrote:
>>
>>
>>>Odi,
>>>
>>>(1) Please take a closer look at the exception stack trace. The exception
>>>is thrown when the server socket gets interrupted while blocked in the
>>>listen method. This exception is perfectly legitimate in this context
>>
>>Okay.
>>
>>
>>>(2) This should not really require a PhD Stanford to figure out that if
>>>you hardware is faster that the one I used to run the test you might
>>>want to tweak the parameters a little in order to make the numbers a
>>>little more representative. Please increase the buffer size and retest
>>
>>Ok, with 10 times as much data (10 MB), I get:
>>
>>Old IO average time (ms): 121
>>Blocking NIO average time (ms): 119
>>NIO with Select average time (ms): 133
>>
>>The jitter is now around 10-15%. So the three values still are all in 
>>the same statistical bucket. That means there is no notable performance 
>>difference below 10 MB of data.
>>
> 
> Odi,
> I think 10-15% performance penalty is considerable.

10-15% is the *jitter*, not the performance penalty. If I measure 133 ms 
for NIO then these 133 ms are an avarage of 20 individual values with 15 
ms of uncertainity each. That means the value 133 ms has an uncertainity 
of 15 ms as well (which is 11%) : The "real" value is between 118 and 
148 ms. So the above numbers have the following meaning:

Old IO average time (ms): 106 - 136
Blocking NIO average time (ms): 104 - 134
NIO with Select average time (ms): 118 - 148

or graphically:

       ******************************* [IO]

     ******************************* [bIO]

           [nbIO]  *******************************

|---------|---------|---------|---------|---------|
100      110       120       130       140       150

Thus it may be possible that, despite the actual figures, nbIO is 
actually faster than IO.

Sorry for being pedantic. It's just that I am a physicist and I was 
taught how to properly perform a measurement.

 > Besides, on some
> platforms, admittedly misconfigured or having poor JRE implementation,
> the cost of having a channel selector per channel is simply prohibitive.
> 
> I am still of an opinion we gain absolutely nothing by using NIO for
> API that is not specifically designed to make heavy use of non-blocking
> IO with hundreds of channels managed by one channel selector.
> 
> Oleg


-- 
[web]  http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp]  key 0x81CF3416
        finger print F2B1 B21F F056 D53E 5D79  A5AF 02BE 70F5 81CF 3416

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org