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 );
}
}
Does it sounds crazy ?
* With this the IoProcessor will be constantly switching between sessions,
checking the state of the session, etc.
See above
* An additional cpu cost will be the increased synchronization efforts inside
the queue... There will be more threads, writing to the same queue at the same
time.
No, because the IoProcessor is using one single thread.
The memory is bought with costs at network throughput and processor cycles.
What do you mean by "it's not a free data structure in term of memory
consumption"?
As far as I understand, a linked queue contains only elements, if there is
something stored in there.
Hmmmm, whatever the queues use, it's irrelevant. There is no reason that
we don't use the same in the IoProcessor queue, as we have the exact
same number of elements in this queue than the number of all the
elements used in all the Session queues.
My expalanition was just plain silly. Thanks for pointing this out.
Pro:
* Behaviour may be more fair.
Write-Throttling may be done by a filter. IMHO It's the better place anyway.
Absolutly.
So you may have the option to place the write throttle at the start of your
queue and save processor speed.
Yes. The problem is to deal with the throttle in a filter, which is not
totally obvious.
Thanks !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
