Hi, Jon!
Thak you for information about IoProcessors. If there are already
cores*2 IoProcessors, than things change much. It seems, that executor
filter is useless at all if a server doesn't perform any waiting/sleeping,
etc. It seems, that executor filter helps, when there are waiting/sleeping
in further server logic. Am i right?
7 окт. 2015 г. 10:40 PM пользователь "Jon V." <sybersn...@gmail.com>
написал:
> It would use more memory and since there is already 2x IoProcessors for cpu
> cores there would be no speedup. In fact it would lead to more memory
> fragmentation/cache misses and require one thread for every session.
>
> Basically, it would be a bad idea.
> On Oct 7, 2015 3:36 PM, "Марат Гайнуллин" <mgaynul...@altsoft.biz> wrote:
>
> > Dear sirs!
> > It is completely clear for me, that decoding of a buffer must be
> linear
> > and tcp messages fragments must be decoded in a serial manner. My
> question
> > is about different thing. Why not to decode SEPARATE sessions' data
> streams
> > in parallel?
> > 7 окт. 2015 г. 10:18 PM пользователь "Jon V." <sybersn...@gmail.com>
> > написал:
> >
> > > You also cannot process a linear buffer simultaneously. TCP is linear
> > and
> > > reading the messages must be linear. After you have a list of messages
> > > then you may execute them in parallel but the line decoding of the
> buffer
> > > must be single threaded. The decoder operates on an inbound buffer and
> > > multi-threading this process will cause the buffers to complete out of
> > > order. There is also no guarantee that the inbound buffer contains a
> > > complete message. In this scenario the tail end of a message could be
> > > processed before the previous part which makes the whole thing totally
> > > broken without locks and locks would just eat more cpu with zero gain.
> > > On Oct 7, 2015 2:53 PM, "Emmanuel Lécharny" <elecha...@gmail.com>
> wrote:
> > >
> > > > Le 07/10/15 20:44, Марат Гайнуллин a écrit :
> > > > > Dear sirs!
> > > > > I am happy to know, that DIRMINA-1013 has been fixed.
> > > > > I have a question. I think, that while decoding TCP messages in
> > > separate
> > > > > sessions, server SHOULD do it in parallel. Why your last comment on
> > > > > DIRMINA-934 was about not to put executor filter before decoder in
> > TCP?
> > > > Because doing so will put your server atrisk. Note that you already
> > have
> > > > more than one thread processing incoming messages (IoProcessors) and
> > TCP
> > > > does not guarantee you that a message will be delivered in one piece.
> > > > Now, let's assume you have an exectir *before* the decoder : then for
> > > > one specific session, more than one thread might be used to decode a
> > > > message, which means that potentially, for fragmented messages, more
> > > > than one thread will be in charge of decoding fration of a message.
> > this
> > > > simply does not fly...
> > > >
> > > > For separate sessions, there is absolutely no problem, because each
> > > > session might be handled by a different IoProcessor.
> > > >
> > > > Performance wise, you might object that while a message is being
> > > > decoded, then another session could be blocked because the thread is
> > > > busy decoding (as the two sessions are handled by the same
> IoProcessor
> > > > thread). that would be true, except that when an IoProcessor thread
> is
> > > > busy decoding, it uses 100% of the CPU of the core it run on, so
> there
> > > > is no 'room' for some other exacution. So having an executor before
> the
> > > > decoder is simply useless, unless you haven't declared as many
> > > > IoProcessors as you have core on your server.
> > > >
> > > > The only case where it's annoying is when your decoder is accessing
> > > > external resources and has to wait for them : unlikely...
> > > > Hope it helps !
> > > >
> > > >
> > >
> >
>
