On 4/18/11 12:14 PM, Julien Vermillard wrote:
Le Mon, 18 Apr 2011 10:26:42 +0200,
Emmanuel Lecharny<[email protected]> a écrit :
On 4/18/11 10:01 AM, Steve Ulrich wrote:
Hi!
I'm sceptical about it. Maybe you could design it in a way, that
the IoProcessor is replaceable, so one could test the behaviour.
And this is why I posted my suggestion on the mailing list :) My idea
might well be totally off base.
Cons:
* Imagine a bunch of smaller write requests per session. Currently
an IoProcessor at least have a chance to optimize the writes by
flushing all data of a single session at once, thus minimizing the
TCP/IP-packages. Under heavy load, a single queue will be stuffed
with a lot of write requests from different sessions and the
IoProcesser will write each one in the order they are written to
the queue, causing a higher fragmentation.
Fair enough. But we can mitigate this risk on the IoProcessor too, by
pulling out of the queue all the messages for a session, until the
socket can't accept any more writing. Something like :
while () {
WriteReqest message = queue.get();
Session session = message.getSession();
Channel channel = session.getChannel();
while ( channel is ready for write) do {
channel.write( message );
message = queue.get( session );
}
}
I think how it's going to behave (vs Queue in the session) will be the
perf of "queue.get( session );".
what kind of structure you want to use ?
I have replied to Steve in another mail, but, yes, this issue has to be
addressed.
It may be one of the reason we want each session to have its own queue.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
