perhaps we should try reading/writing direct buffers
On Sat, Jan 5, 2013 at 8:23 PM, Jeff MAURY <jeffma...@gmail.com> wrote: > I'm working on the netty server. It should be ok by the end of the > week-end. > Regarding the performance for large message, should'nt it be related to jni > i mean the conversion from the java bytebuffer to a memory array that is > expected by the os socket layer ? > > Jeff > Le 5 janv. 2013 19:42, "Emmanuel Lécharny" <elecha...@gmail.com> a écrit : > > > Le 1/5/13 7:21 PM, Jeff MAURY a écrit : > > > No, I did not mean there's a bug but what I meant is that when Mina2 > has > > to > > > write a large message, it will split the message in small parts when > > > writing to the socket whereas Netty tries to write the full message to > > the > > > socket (as Mina3 from what you said). This may explain why Netty > becomes > > > slower for large messages like Mina3 > > Ah, ok. > > > > However, the way it *should* work, in any case, is that you should > > always try to send as much data as you can, assuming also that the > > send/received buffer are correctly sized initially. > > > > What I don't get is how it can make any difference to write the whole > > message into the socket, because the socket won't accept more than what > > it can store. I was expecting that you will loop as many times as the > > socket can absorb, waking up the select() as soon as the socket s ready > > to accept more data. > > > > Anyway, I have to investigate why MINA 3 is so damn slow when it comes > > to send big messages, compared to MINA2. There is no reason for such a > > gap in performance. This is also true for Netty, btw. > > > > Last, not lesat : the test with Netty just vovers the > > NettyClientMina2Server. We need a test with NettyClientNettyServer (and > > probably with the two latest Netty versions). > > > > -- > > Regards, > > Cordialement, > > Emmanuel Lécharny > > www.iktek.com > > > > >
