Le 9/12/12 4:28 PM, Antonio Rodriges a écrit :
2012/9/12 Emmanuel Lécharny <[email protected]>:
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
In order we could return the result quickly for the first query (not
waiting the end of all read operations) we can have two sessions per
client: one for read requests, the other for write. Will this make
sense?
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
So we have separate write queues for separate sessions?
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.
I was talking about many clients having one session because we use
this implementation now (and, BTW not used before). One of the
approaches is to have one session per one thread (since potentially
each thread is a client). However, this yields many opened files on
the server side. So, the protocol simply addes additional field
(recepient thread id) to determine the recepient thread on the client
side.
Ah, so you are multiplexing the sessions.
Just a question : why is it a problem to have many opened files ? Plus
why would you use one thread per session ? (if you do that, you'd better
use BIO, it's 30% faster).
Now I see we must have separate sessions for each thread (at least for
some application parts). And even more: at least two sessions - one
for read the other is for write?
I think there is some misunderstanding here. When I mention Session, I
mean the IoSession instance associated with the connection. If your many
clients are using one single IoSession, then it's a different story.
At this point, I need a better description of what you are trying to do...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
