[undertow-dev] TransferTo/sendfile Undertow v1.0.x vs 1.1.x

[Dave O'Brien]

Hi everyone,

I wanted to run this 'issue' past the experts, as I've looked into it
myself and hit a bit of a dead end.

Our application is using Undertow 1.0.17 for serving both static and
dynamic Web content. We did some benchmarking early on in the development
of our app and got some very impressive results.

On a modest server with undertow 1.0.17, using wrk defaults we get around
50k rqsts/s for a 2kb file and about 17k rqsts/s for a 100kb file. So far,
so (very) good.

I recently tried updating to version 1.1.2 and ran the original tests and
got similar results as for v1.0.17 for the 2kb file. For the 100kb file,
however the throughput dropped to about 10k rqsts/s.

Not the end of the world, I know but I decided to dig around and see what
was (or wasn't) going on....

Our app has a sendfile threshold (64k), that above which we use the
ResponseChannel 'TransferTo' method, which performs (on Linux anyway) a
native zero-copy sendfile operation using the Java NIO
FileChannel.transferTo call (which calls into Linux sendfile under the
covers if certain conditions are met).

In v1.0.x, the native sendfile method (transferTo0) is ultimately invoked
to send the content. But in v1.1.x (and 1.2.x also) the transferTo method
in the FileChannel instead opts to invoke transferToArbitraryChannel which
resorts to a kernel -> user space copy and a not-insignificant drop in
throughput.

So my question is, is this change across the versions deliberate, a
sacrifice for improvements elsewhere - or is it a bug?

If it's a bug I'm happy to re-instate the native sendfile functionality
myself, but I wanted to check it was an issue first...

Thanks in advance for any assistance/advice on this one...

David.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150312/631ff89a/attachment.html