From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Vladislav Shpilevoy Subject: [PATCH v2 0/4] IProto fixes and iproto_msg_max option Date: Mon, 23 Apr 2018 20:05:00 +0300 Message-Id: To: tarantool-patches@freelists.org Cc: vdavydov.dev@gmail.com List-ID: 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. 'iproto_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. 'iproto_msg_max' can be decreased, but obviously it can not stop already runned requests, so if now in IProto thread request count is > new 'iproto_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 incorrect discarding long-poll requests input. Discard just calls iproto_resume() trying to notify libev, that is can get new data. But is makes no sense, because iproto_resume() continues only connections stopped due to reached limit of maximal requests in fly, but not connections whose buffer is overflowed. Such stopped connections can be continued only after a request is complete. To continue read from the connection whose buffer was freed by discarding long-poll it is necessary to explicitly feed to it EV_READ event. On this event iproto_connection_on_input will read a blocked data if it exists. Another fixed bug is unstoppable batching ignoring the message limit on IProto requests. Vladislav Shpilevoy (4): iproto: fix error with input discarding iproto: fix error with unstoppable batching iproto: allow to configure IPROTO_MSG_MAX Allow to configure TX fiber pool size src/box/box.cc | 16 +- src/box/box.h | 1 + src/box/iproto.cc | 111 ++++++++++---- src/box/iproto.h | 3 + src/box/lua/cfg.cc | 12 ++ src/box/lua/load_cfg.lua | 5 + src/fiber_pool.h | 6 +- test/app-tap/init_script.result | 73 ++++----- test/box/admin.result | 2 + test/box/cfg.result | 27 ++++ test/box/cfg.test.lua | 10 ++ test/box/fat_tx.lua | 30 ++++ test/box/request_limit.result | 321 ++++++++++++++++++++++++++++++++++++++++ test/box/request_limit.test.lua | 155 +++++++++++++++++++ 14 files changed, 704 insertions(+), 68 deletions(-) create mode 100644 test/box/fat_tx.lua create mode 100644 test/box/request_limit.result create mode 100644 test/box/request_limit.test.lua -- 2.15.1 (Apple Git-101)