[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mina-dev
Subject:    Re: IoProcessor & write operations
From:       Emmanuel Lécharny <elecharny () gmail ! com>
Date:       2012-09-28 14:09:37
Message-ID: 5065AFA1.1070403 () gmail ! com
[Download RAW message or body]


I have made a little experiment in UDP :
- I added the write(Session, WriteRequest) method in the IoProcessor
interface
- in the DefaultIoFilterChain.HeadFilter.filterWrite() method, I check
if the write queue is empy, and if so, I call the write(Session,
WriteRequest) method instead of pushing the WriteRequest into a queue,
adding the session into the list of sessions to flush, and calling the
flush(session) method
- as the IoProcessor interface has changed, I have also added the
implementing classes, and in order to work even if the write queue is
empty, I copied the existing code from the HeadFilter.filterWrite()
method there, so the other protocols still work the same way

The result is quite interesting : it's eating 20% less CPU than when we
were going through a queue.

I also compared the UDP performance test on 2.0.4 and trunk :
- it takes 34.3 seconds, and uses 45% CPU with MINA 2.0.4 to run this test
- it takes 25.88 seconds, and uses 30% CPU on trunk.

Baseline, MINA consume less CPU and time with the changes done on trunk,
leaving more 'room' for applications to execute.

This is true for UDP, but if we except the write part, on TCP the code
is a bit better, and there is not such an order of improvement to
expect. However, we could spare some cycles by writing directly in the
socket, if it's ready.

Two last points :
o Statistics are quite expensive to generate, it could be a good idea to
have them disabled by configuration
o If the application des not care about the messageSent() event, then we
should be able to tell the server that we don't want to receive such a
message. That could save a few CPU too.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com




[prev in list] [next in list] [prev in thread] [next in thread]