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.
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 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
