Instead of relying on logging; I would setup a stress test to measure completed commands/s and use that as a foundation for trying other procedures.
On Sat, Feb 22, 2014 at 7:03 AM, Max Larsson <[email protected]>wrote: > Hi, > > >> .... > >> > >> In my IoHandler i receive the desired message and write out the response >>> to session.write. But it is not immediately written out. During my >>> process of the message additional message are received and process >>> before my response message is delivered. >>> >> >> It all depends on the session processing the incoming message. This is a >> multi-threaded framework, messages comming from dfferent sessions may be >> processed in //. >> > > OK because, i implement the client i only have one session, thus this > doesn't complicate my issue. > > Now i figured out that only one thread handles read/write request. >>> >> Absolutely. >> >> And >>> the read request is processed before any write request? >>> >> >> depends. If the socket is full when the thread is trying to write into >> it, then it give up, and a new incoming message might be processed >> before the write can be done. Eventually, a lot of messages can be >> stacked waiting for being written. >> > > So how can i >>> either have a separate Thread for sending and receiving. >>> >> >> You can use an Executor in the chain, even two executors if needed (one >> for reads, one for writes). But at the nend of the day, it does not >> somlve your issue. >> >> Or alternative >>> how to tell the NioSocketprocess to take priority processing of write >>> requests? >>> >> >> You can idle the read while the write is not processed. The way it works >> woudl be something like : >> >> - process a read (in the handler) >> - idle the read (session.suspendRead()) >> - write the response >> >> Then in the handler, react on the messageSent event : >> >> - process the messageSent event >> - un-idle the read (session.resumeRead()) >> >> You now can process a new read. >> >> Think twice before implementing such a logic though !!! I would question >> the fact that the client is sending messages but not reading the >> response fast enough... >> > > You correct, your purposed solution doesn't solve my issue. At least > i tried the ExecutorFilter, the suspendRead solution feels already from > the reading ugly, so i didn't give it try. And because i'm the client > i think i have a performance problem. But my investigation shows me > that from receiving the command in my IoHandler to writing the response > with session.write i need around 2 ms. But than it takes about 70 ms to > get a logging about form the NioProcessor saying it send the message. > > Normally the NioProcess will not received any additional commands from > between the first and sending my response. But under heavy load it will > receive additional commands before sending my response and thus delay > it additional about some ms. > > My goal is to get this 70ms as low as possible, and you say the cause > for the long processing time is that the socket is full? Can a socket be > full because of message collisions on the wire? > > Oh by the way i know i can get faster, because in raw cases the 70ms > drop down to 2ms. Thus the whole command response cycle is processed > in about 4ms. > > best regards > > Max > > -- > _____________________________________________________________________ > > http://facilityboss.biz > http://facebook.com/facilityboss > _____________________________________________________________________ > > Max Larsson > facilityboss GmbH > Rheinstrasse 75, 64295 Darmstadt / Germany > Handelsregister Darmstadt, HRB 86193 > Geschäftsführer: Dipl.-Inform. Max Lars Robert Larsson > > Mobil: +49 179 2184428 > Email: [email protected] >
