2012/9/12 Emmanuel Lécharny <elecha...@gmail.com>: > 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. 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?
