Emmanuel, you're absolutely right! I patched the MINA source code (1.1 branch) removing all calls to Socket.setReceiveBufferSize() (just for the test), and voila - no more bottlenecks. The MINA implementation reaches the same throughput as the simple servers.
The strace log indeed shows that there is a call to setsockopt(...SO_RCVBUF...) after the bind call. First, I really appreciate your work on the framework, it's very easy to work with and has really cool features, but I have to say that it is bad that the out-of-the-box performance of MINA is so poor. This simple performance comparison test should always be verified throughout MINA releases. Second, why mass around with the receive buffer anyway if the user didn't explicitly wants to? let the OS manage it... Can you please release a patched version of MINA 1.1.7 with a fix? Thanks guys. On Thu, Nov 26, 2009 at 8:10 PM, Emmanuel Lecharny <[email protected]>wrote: > Might be related to http://issues.apache.org/jira/browse/DIRMINA-561 > > Also read > http://java.sun.com/j2se/1.5.0/docs/api/java/net/ServerSocket.html#setReceiveBufferSize(int): > > "It is possible to change the value subsequently, by calling > |Socket.setReceiveBufferSize(int)| < > http://java.sun.com/j2se/1.5.0/docs/api/java/net/Socket.html#setReceiveBufferSize%28int%29>. > However, if the application wishes to allow a receive window larger than 64K > bytes, as defined by RFC1323 then the proposed value must be set in the > ServerSocket *before* it is bound to a local address. This implies, that the > ServerSocket must be created with the no-argument constructor, then > setReceiveBufferSize() must be called and lastly the ServerSocket is bound > to an address by calling bind(). " > > > Zvika Gart wrote: > >> And here are the logs >> >> On Thu, Nov 26, 2009 at 7:19 PM, Zvika Gart <[email protected]> wrote: >> >> >> >>> 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. >>>>> >>>>> >>>>> >>>>> >>>> >> >> > > > -- > -- > cordialement, regards, > Emmanuel Lécharny > www.iktek.com > directory.apache.org > > >
