Separate the fast and slow commands in the second phase, dynamically adjust the fast and slow command settings according to the access time, and dynamically adjust the number of coroutines and pika threads

[chejinge]

Which PikiwiDB functionalities are relevant/related to the feature request?

No response

Description

动态调整运行过程中的快慢命令

Proposed solution

动态调整运行过程中的快慢命令

Alternatives considered

动态调整运行过程中的快慢命令

[chejinge]

刘欢负责推进

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

Liu Huan is responsible for promoting

[happy-v587]

关于快慢命令的几个问题和方案需要确定下：

方案：

1、计划添加是否开启自动发现慢命令参数，默认开启，也支持关闭。最终实现三种模式的慢命令设置：纯自动配置(程序自动哦发现)、纯手动配置(现在的方式)、手动配置 + 自动配置。这样是否可以？

2、关于慢命令执行时间设置：添加慢命令执行时间阈值参数，默认1s，是否可行？未来这个值可基于当前负载动态计算出来

3、慢命令如何更优判定 如果一个cmd的请求超出这个时间阈值，就立刻判断为慢命令吗？还是做一些平滑计算？同理如何从慢命令集合摘除？目前想到的一些策略如下：

• 一次执行时间 大于/小于 阈值就 添加/摘除 ？
• 连续N次执行时间 大于/小于 阈值就 添加/摘除？
• 滑动窗口内N次执行时间 大于/小于 阈值就 添加/摘除？
• 滑动窗口内平均执行时间 大于/小于 阈值就 添加/摘除？

性能：

4、对于第3的实现，可能需要申请N个全局map+atomic(提高并发)做数据统计，这样pika性能应该会有下降，需要权衡下

其他：

5、如果一个 cmd 的某个 key 是 bigkey，那么这个 cmd 就被判定为慢命令是否合理？未来是否会考虑到key维度？

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

Several questions and solutions regarding fast and slow commands need to be determined:

plan:

1. Plan to add the parameter Whether to enable automatic discovery of slow commands. It is enabled by default and can also be disabled. Finally, three modes of slow command settings are implemented: pure automatic configuration (automatic discovery by the program), pure manual configuration (current method), manual configuration + automatic configuration. Is this okay?

2. Regarding the slow command execution time setting: Add the slow command execution time threshold parameter, the default is 1s, is it feasible? In the future this value can be calculated dynamically based on the current load

3. How to better determine slow commands? If a cmd request exceeds this time threshold, will it be immediately determined to be a slow command? Or do some smoothing calculations? In the same way, how to remove it from the slow command set? Some strategies that come to mind so far include:

• One execution time greater than/less than threshold is add/remove?
• N consecutive execution times greater than/less than, the threshold is add/remove?
• The threshold of N execution time greater than/less than within the sliding window is add/remove?
• The average execution time in the sliding window is greater than/less than, and the threshold is add/remove?

#Performance:

4. For the third implementation, it may be necessary to apply for N global map+atomic (to improve concurrency) for data statistics. In this way, the performance of Pika should be reduced, and it needs to be weighed.

other:

5. If a key of a cmd is bigkey, is it reasonable for this cmd to be judged as a slow command? Will the key dimension be considered in the future?

[happy-v587]

关于动态调整线程数的一些问题和方案：

方案

1、线程数动态调整策略：判断线程池中queue的task个数，如果挤压超过某个阈值就添加新的thread，如果长时间空闲就回收thread。添加可以一次多个，回收逐次-1

2、快慢命令使用统一线程池：仿照rocksdb，支持Priority::HIGH、Priority::LOW

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

Some issues and solutions about dynamically adjusting the number of threads:

plan

1. Dynamic adjustment strategy for the number of threads: determine the number of tasks in the queue in the thread pool, add new threads if the squeeze exceeds a certain threshold, and recycle threads if they are idle for a long time. You can add more than one at a time, and recycle -1 each time.

2. Fast and slow commands use a unified thread pool: modeled after rocksdb, supporting Priority::HIGH and Priority::LOW