[server-dev] [RFC] Interactive transactions in IProto
Vladislav Shpilevoy
v.shpilevoy at tarantool.org
Thu Nov 15 14:09:07 MSK 2018
On 15/11/2018 11:30, Vladimir Davydov wrote:
> On Wed, Nov 14, 2018 at 05:09:48PM +0300, Vladislav Shpilevoy wrote:
> > More questions to think about:
> >
> > 1. How to balance streams processing? How to choose from which stream
> > of many ones TX thread should pick up a request? I think, round-robin
> > is fair enough, but maybe I am wrong.
>
> I'd rather leave all the balancing to the fiber scheduler. IProto would
> simply queue responses to the appropriate stream to be processed by the
> fiber that is currently executing a request that belongs to the same
> stream, or if there's none, start a new fiber.
>
> >
> > 2. How about storing and balancing request queues in iproto thread?
> > I think we should not waste TX thread time on this pure technical
> > things. The only problem I see, it requires storing struct txn * in
> > iproto thread inside struct stream (or any other struct <name>).
>
> We could probably queue all requests that belong to the same stream
> internally in IProto before sending them to TX in one batch, if that's
> what you mean.
>
> Come to think of it, there's another question. How is this feature going
> to play with net_msg_max limit? Suppose there's a hundred messages
> queued to the same stream. Do we need to account them all to
> net_msg_max? Or rather account distinct streams only?
>
net_msg_max is 'msg', not 'stream', so I believe it should limit
messages, not streams. At least, until we use Kharon to do not keep
iproto_msg during IPROTO_CALL/EVAL execution.
More information about the Tarantool-discussions
mailing list