From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 8051F2253C for ; Thu, 3 May 2018 17:05:23 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QA1t9w36vPGR for ; Thu, 3 May 2018 17:05:23 -0400 (EDT) Received: from smtp43.i.mail.ru (smtp43.i.mail.ru [94.100.177.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id BB7592170F for ; Thu, 3 May 2018 17:05:22 -0400 (EDT) From: Vladislav Shpilevoy Subject: [tarantool-patches] [PATCH v2 0/2] IProto fix and net_msg_max option Date: Fri, 4 May 2018 00:05:18 +0300 Message-Id: Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-subscribe: List-owner: List-post: List-archive: To: tarantool-patches@freelists.org Cc: kostja@tarantool.org Branch: http://github.com/tarantool/tarantool/tree/gh-3320-config-msg-max Issue: https://github.com/tarantool/tarantool/issues/3320 IPROTO_MSG_MAX is a constant that restricts count of requests in fly. It allows to do not produce too many fibers in TX thread, that would lead to too big overhead on fibers switching, their stack storing. But some users have powerful metal on which Tarantool IPROTO_MSG_MAX constant is not serious, or they want to run more long-poll requests. The patch exposes it as a configuration runtime parameter. 'net_msg_max' is its name. If a user sees that IProto thread is stuck due to too many requests, it can change iproto_msg_max in runtime, and IProto thread immediately starts processing pending requests. 'net_msg_max' can be decreased, but obviously it can not stop already runned requests, so if now in IProto thread request count is > new 'net_msg_max' value, then it takes some time until some requests will be finished. Maximal IProto message count is very linked with TX fiber pool size, that limits count of fibers produced by remote clients, and transactions. Now it is configurable too. In the same patchset a bug is fixed with unstoppable batching ignoring the message limit on IProto requests, and iproto connection resuming is reworked to separate connection resuming and new data reading. Vladislav Shpilevoy (2): iproto: fix error with unstoppable batching iproto: allow to configure IPROTO_MSG_MAX src/box/box.cc | 11 +- src/box/box.h | 1 + src/box/iproto.cc | 220 ++++++++++++++++++++++++++++------------ src/box/iproto.h | 3 + src/box/lua/cfg.cc | 12 +++ src/box/lua/load_cfg.lua | 3 + src/fiber_pool.c | 14 +++ src/fiber_pool.h | 14 ++- test/app-tap/init_script.result | 55 +++++----- test/box/admin.result | 2 + test/box/cfg.result | 27 +++++ test/box/cfg.test.lua | 10 ++ test/box/errinj.result | 69 +++++++++++++ test/box/errinj.test.lua | 29 ++++++ test/box/net_msg_max.result | 134 +++++++++++++++++++++++- test/box/net_msg_max.test.lua | 72 ++++++++++++- 16 files changed, 574 insertions(+), 102 deletions(-) -- 2.15.1 (Apple Git-101)