Regarding the message size, I noticed that Mina2 writes only a sub part of the message (size is computed from the receive buffer size if I remember correctly) whereas Netty tries to write the buffer buffer to the socket. So If you did the same in Mina3, it may explain why it is slow
Jeff On Sat, Jan 5, 2013 at 9:12 AM, Julien Vermillard <[email protected]>wrote: > Houura :-) > The default socket buffer size is changed by mina 2 ? > Le 5 janv. 2013 06:26, "Emmanuel Lécharny" <[email protected]> a écrit > : > > > Some more results after the modification I suggest at the end of my last > > mail (ie, do the write immediately, instead of using a queue, when we > can) > > : > > > > Mina3 client/ Mina3 server : 10bytes msgs in 38.6 secs | 1k msgs in 42.2 > > secs | 10k msgs in 45.7 secs > > > > This is a clear 50% speedup compared to my previous MINA 3 perfs, and 33% > > increase compared to the Netty scenario. > > > > I still have some more code to fix to get this working fo UDP, as I > > added a writeDirect() method into the IoSessin interface I now have to > > implement for each class. > > > > Also note that, compared to MINA 2, the forth test (ie, transfering > > large messages - 64Mo) is extremely slow - as for Netty -. There is most > > certainly somethng to do regarding the buffer size we use to transfer > > such big Messages. > > > > > > Le 1/4/13 5:51 PM, Emmanuel Lécharny a écrit : > > > Hi ! > > > > > > I conducted some profiling sessions today, to see where we were spening > > > some spurious CPU in MINA3. When I first did some tests, I was able to > > > process 1 million 10 bytes messages in 75 seconds (the message is > > > written by the client, read by the server, which returns a 1 bte > message > > > to the client). This is the very same test than the one Jeff wrote for > > > MINA 2 and Netty. > > > > > > After a bit of analysis, I was able to lower this number to 57 seconds. > > > > > > Now, here are the numbers for MINA 3, MINA 2 and Netty, for 1M > messages : > > > > > > Mina3 client/ Mina3 server : 10bytes msgs in 57.8 secs | 1k msgs in > 53.2 > > > secs | 10k msgs in 66.1 secs > > > Mina2 client/ Mina2 server : 10bytes msgs in 53.4 secs | 1k msgs in > 52.4 > > > secs | 10k msgs in 75.6 secs > > > Netty client/ Mina2 server :10bytes msgs in 51.4 secs | 1k msgs in 49.6 > > > secs | 10k msgs in 74.7 secs > > > > > > (we currently don't have a Netty server) > > > > > > So bottom line, MINA 3 is slower than any other combinaison, despite > the > > > minimal features we have injected, except for big messages. Is this a > > > problem ? Well, yes and no. > > > > > > There are some very good reasons for MINA 3 to be slower : we call the > > > selector.select() method for every message we have to send. This is the > > > most expensive part of the code, and it's not something we can improve > : > > > we don't have any way to make select() go faster. > > > > > > OTOH, we could call select() less often. Right now, what we do is that > > > everytime we exit from a select(), we process all the activated > > > SelectionKey we get. This is done by calling the ready() method, with > > > flags indicating which event we have to process (OP_READ and OP_WRITE > > > mainly). > > > > > > The ready() method processes the connect, read, wrate and accept > events, > > > one after the other. The thing here is that if a read results in some > > > writes, the writes will be processed in the next select() loop, when in > > > Netty and MINA2 it's potentially processed just afterward, in the same > > > select() loop. > > > > > > We can bypass this extra loop most of the time, as soon as the channel > > > is ready. The idea is to push the message into the channel, if we don't > > > have anything in the writeQueue, and we are done. If the writeQueue is > > > not empty, we simply push the message in the queue. Last, not least, if > > > we weren't able to write all the message, we push the remaining message > > > on the writeQueue, set the SelectKey OP_WRITE to true, and wake up the > > > selector. That would save us a lot of CPU for small messages. > > > > > > I will try to do that. > > > > > > > > > -- > > Regards, > > Cordialement, > > Emmanuel Lécharny > > www.iktek.com > > > > > -- Jeff MAURY "Legacy code" often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury
