Le 9/12/12 8:36 AM, Antonio Rodriges a écrit :
Hello, Brendan & Emmanuel,
Sorry for joining the discussion too late. I am just interested on the
details since we have also Mina-based application with high read/write
rates.
Our clients issue queries and wait for respose. A client does not
issue new query until it receives a respose. We use single session for
a multithreaded client.
Emmanuel, as far I understood, IoProcessor loops until it has
something to read for a session.
Not exactly. IoProcessor does a select(), which is blocking (and consume
no CPU at all) until some socket becomes active (either ready to read or
write, or newly connected).
When it finishes, it starts writing
and writes until it has something to write?
For each session that has been activated, it process the read, and when
done, process the write. That means that, if we have, say, 10 activated
sessions, we will do 10 read/write actions (we may not write anything
thoungh.
Also keep in mind that a session can write but not read - for instance
if we have a big message to send but we weren't able to write all the
data in the previous loop - or read and not write.
Brendan, do your clients interact with the server and do not wait for
a response? Did you try two separate sessions, one for incoming
messages and another for outgoing ones?
Seems like we must also investigate the possibility of separating
in/out message queues.
Also, when using ExecutorFilter and several IoProcessors for both in
and out queues, we, theoretically, may additionally achive speedup due
to the load disribution. This is when only read first and only write
after that sequence takes place inside a single session (i.e. for
session 1 we can read while for session 2 we can write concurrently
with different IoProcessors).
Emmanuel, is it true: IoProcessor will not forward on to the next
outgoing message until its buffer will not be comletely written to the
network or system buffer or smth else?
No. Reads and writes are not correlated. When you do a session.write()
in your handler, at least two messages are written in a write queue. The
IoProcessor will peek messages from this write queue and write them in
the socket until the socket is full, and will start again writing when
the socket is OP_WRITE ready. You may receive many messages in the mean time
(FTR, we write two messages for a simple reason - and it's a trick - :
the first message contains the data to be sent, the second message is
empty and is just used to notify the stat counter that a message has
been sent. The client will *never* receive this second message. We have
to do that because those messages contains byte[], and we have no idea
about their boundaries)
If so, having N big responses that must go through the same sessiion
and large enough buffer, and, say 40 ms to transfer each, the first
client will receive the response in (approx) 40 ms, the next in 80 ms,
3rd in 120 ms, etc.
If you have more than one client, then you will have more than one
session. Your numbers are not what you'll experiment.
Is it correct? If so, is there a way to have several threads writing
to the same session concurrently (since in any way we have multicore
CPUs)?
Again, if you have many clients connected to the server, then you will
have as many session. A session is used for every socket, and a client -
server connection will use one socket. So if you have more than one
client, you'll have more than one socket, thus more than one session.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
