Attached are the strace logs with the trace=network for the MINA implementation and the simple NIO implementation. both ran for about 30 seconds. As you can see the MINA implementation makes lots of getsockopt system calls to get the receive buffer size (for each receive?).
In this link http://79.125.32.246/capture.tbz you can find tcp dumps of the two implementations. ACK patterns are affected by the capabilities of the receiving application - how fast it reads data from the socket. You can see that the window size in the MINA implementation doesn't grow and is stuck at about 64KB while in the simple NIO it gets to 2MB. This is probably because the MINA implementation is slow at reading from the socket. If you need more logs or want me to run further tests please let me know. On Thu, Nov 26, 2009 at 4:04 AM, Tuure Laurinolli < > [email protected]> wrote: > >> Zvika Gart wrote: >> >>> - Check if there are some differences in the traffic (e.g. TCP ACK >>>> patterns) >>>> >>> >> You didn't say anything about this yet. >> >> >> - Check syscall patterns of the MINA version and try to see if something >>>> is >>>> taking unreasonably long time (pure NIO implementation might be helpful >>>> here) >>>> >>> >> - As for syscall patterns, I'll need your help as I am a .NET programmer >>> and >>> not familiar with Java/Linux profiling... >>> >> >> Have you ever done anything with the Sysinternals file monitoring tools? >> Strace is similar tool for Linux, except its output is textual. You should >> find and read some tutorial about it to get some idea of how to use it. >> >> For an actual test run, something along the lines of "strace >> -o/tmp/traceout -f -s2048 -tt -e trace=network java -jar myserver.jar" >> should output all network-related syscalls that your process performs to >> /tmp/traceout. You'll have to the comparing yourself, though. >> >> I'd expect there to be epoll() calls in MINA case, and if there is >> something to read, recv() calls to read it. The threaded blocking version >> should probably just sit blocking in recv(). I'd try to minimize other thing >> going on in the same process for the test, since there will probably be >> enough noise in any case. >> >> >
