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 ?
>
> 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 !
>
--
Julien Vermillard
Archean Technologies
http://www.archean.fr
signature.asc
Description: PGP signature
