hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [HttpCommon] NIO is one huge disappointment
Date Thu, 18 Aug 2005 11:29:53 GMT
On Thu, Aug 18, 2005 at 12:00:24PM +0200, Ortwin Gl?ck wrote:
> 
> 
> Oleg Kalnichevski wrote:
> >Odi,
> >
> >As soon as I see NIO w/ select outperform old IO by 10-15% at least
> >ONCE I may believe this is just a statistical jitter. Until then old IO
> >consistently outperforming NIO w/select by 10-15% looks horribly like 
> >a performance penalty to me ;)
> 
> Yes, this is what a reasonable brain does. I tend to think the same way, 
> even though it is not accurate in scientific terms.
> 
> >You are welcome to give System.nanoTime() method a shot which supposedly
> >is more precise than System.currentTimeMillis()
> 
> Good idea. I have never used it before.
> 
> >I have put WAY more effort into writing the damn NIOHttpDataReceiver
> >than the entire HTTP coyote connector, and it REALLY pains me to have 
> >found this code useless (at least in HttpCommon). At the same time I 
> >rather keep HttpCommon lean and mean, and use NIO where it make sense, 
> >that is in HttpAsynch.
> >
> >Oleg
> 
> That is a bit of a disappointment of course. But this is only a 
> laboratory test. With a real load (multiprocessor, many connections, 
> heavy load) the figures could be the other way round. But see the good 
> side: you can now exchange the implementation easily now. Your efforts 
> have certainly not been spent for nothing!
> 
> Odi
> 

Odi,

Mistakes and design flaws can be expected in the course of development.
We just have to be able to admit them and after having done so fix the
problems. Presently NIO just does not seem to provide any tengible
benefits for blocking i/o at the price for much, much greater
complexity. I hoped the NIO should enable us to be more efficient when
parsing HTTP headers, if byte to char conversion could be sped up with
ByteBuffer, CharBuffer, and Char*coders. However, if one saves a few
milliseconds parsing HTTP headers and loses several times more when
retreiving the content, it just does not make a lot of sense to me.

I do not mind leaving NIO based HTTP data receiver and transmitter
alone, if you think it is still premature to give up on NIO yet.
However, we'll have to revist this problem before the new API is frozen. 

Cheers,

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
> 
> 

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


Mime
View raw message