[prev in list] [next in list] [prev in thread] [next in thread] 

List:       httpclient-commons-dev
Subject:    Re: [HttpCore] non-blocking NIO HTTP transport (server and client
From:       Oleg Kalnichevski <olegk () apache ! org>
Date:       2006-10-29 18:54:40
Message-ID: 1162148080.5862.38.camel () localhost ! localdomain
[Download RAW message or body]

On Sun, 2006-10-29 at 19:26 +0100, Robert Olofsson wrote:
> Oleg Kalnichevski wrote:
> >> One thing for the wish list that could be nice to have: support for
> >> FileChannel.transferTo and FileChannel.transferFrom. At least on linux
> >> they become sendfile. If you want to build a fast web server it is
> >> needed. The api for transferTo/From is a bit different from read + write
> >> since data is never in user space. Any thoughts?
> > 
> > This would call for some really hard design decisions. One can either
> > (1) expose the underlying socket channel in the public API, which is
> > kind of bad IMO or (2) extend ContentDecoder and ContentEncoder
> > interfaces with methods that take FileChannel as an input parameter.
> 

I'd probably go with the second option and make this facility available
through an optional interface

interface ContentContentDecoder extends ContentDecoder {

 void writeDirect(FileChannel channel, ...);

}

> Yes it would require api changes. You can of course add layers of api
> on top of it to hide some parts of it.
> 
> > I am not sure this all is worth the trouble, as the raw throughput is
> > certainly not one of NIO's strong points. As far as I can tell classic
> > blocking IO easily outperforms NIO in terms of raw throughput by as much
> > as 2 to 3 times, when the number of concurrent connections is around
> > 200. I doubt the use of FileChannel#transferTo/From would dramatically
> > change the situation.
> 
> I am not sure that that is a well done benchmark. I do not have any good
> benchmarks myself to compare blocking vs selector based io. I could
> perhaps use my proxy to try it, but it has changed quite a lot since the
> change from threaded io.

I'd be happy to be proved wrong, but this is what I have been seeing so
far. This is also consistent with the experience of Tomcat developers. 

I use AB (Apache benchmark) to measure performance of HTTP transports
and as far as I can tell this can be hardly considered an extravagant
way of performing HTTP benchmarks. 

At some point mainstream JVMs may improve and NIO performance will match
that of classic IO, but with JVMs widely deployed today blocking IO
appears clearly ahead in terms of the raw throughput. 

Anyways, I am very open to reconsidering my attitude towards NIO given
enough empirical data. 

Cheers

Oleg

> 
> I could benchmark my proxy with and without transferTo/transferFom
> though, that could be an interesting benchmark and that is easy to
> check.
> 
> /robo
> 
> ---------------------------------------------------------------------
> 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

[prev in list] [next in list] [prev in thread] [next in thread]