and pushed a potential fix for
this upstream to both the master and 1.1.x branches. Can you try it out and see if it
resolves your issue?
----- Original Message -----
From: "Dave O'Brien" <davidpobrien(a)gmail.com>
Sent: Friday, 13 March, 2015 10:33:43 AM
Subject: [undertow-dev] TransferTo/sendfile Undertow v1.0.x vs 1.1.x
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
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
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...
undertow-dev mailing list