<span style="background-color:rgba(255,255,255,0)">Hi everyone,</span><br><div><font><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font><span style="background-color:rgba(255,255,255,0)">I wanted to run this 'issue' past the experts, as I've looked into it myself and hit a bit of a dead end.</span></font></div><div><font><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font><span style="background-color:rgba(255,255,255,0)">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.</span></font></div><div><font><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font><span style="background-color:rgba(255,255,255,0)">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.</span></font></div><div><font><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font><span style="background-color:rgba(255,255,255,0)">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.</span></font></div><div><font><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font><span style="background-color:rgba(255,255,255,0)">Not the end of the world, I know but I decided to dig around and see what was (or wasn't) going on....</span></font></div><div><font><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font><span style="background-color:rgba(255,255,255,0)">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).</span></font></div><div><font><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font><span style="background-color:rgba(255,255,255,0)">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.</span></font></div><div><font><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font><span style="background-color:rgba(255,255,255,0)">So my question is, is this change across the versions deliberate, a sacrifice for improvements elsewhere - or is it a bug?</span></font></div><div><font><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font><span style="background-color:rgba(255,255,255,0)">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...</span></font></div><div><font><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font><span style="background-color:rgba(255,255,255,0)">Thanks in advance for any assistance/advice on this one...</span></font></div><div><font><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font><span style="background-color:rgba(255,255,255,0)">David.</span></font></div>
<br>