环境说明:
操作系统: ubuntu 22.04
内核版本: 5.15.0-119-generic
系统架构: x86_64
EMQX版本: 开源版 5.8.9
情况说明:
单节点配置listeners.tcp.default.max_conn_rate=“10/s”,然后进行连接测试.实测结果均出现: 第一秒的第18/19个客户端才会被阻拦,之前的均正常登录,该配置项无法准确阻拦客户端登录.
测试方案:
- 方案一: 每秒并发20个客户端发起连接,客户端总数20个
- 方案二: 每秒并发20个客户端发起连接,客户端总数400个
测试结果:
- 方案一: 18个客户端连接成功,2个失败
- 方案二: 207个客户端连接成功, 183个失败
测试过程中发现在只在第一秒的第19个客户端才会被阻拦,之前的18个都登录成功
- 方案一测试截图
- 方案二测试结果
我该如何配置才能准确的进行限速.
统计是没有那么精准的。不然会严重影响性能。
不过在 6.3 的版本后，对这个有比较大的优化，应该会更准一点。但是达不到你说的这么精准。
看了下源码。补充更正一下：这个现象不只是统计精度问题。EMQX 5.8.9 的 max_conn_rate 使用令牌桶，10/s 大致按每 100ms 补充 1 个令牌，桶最多可积累 10 个。它限制的是持续接入速率，并不是“任意连续 1 秒最多成功 10 个”。
从图中看，第一组 18 条 Connected 的时间约为 11:35:13.950 到 11:35:14.754，历时约 804ms，连接大致每 50ms 发起一次。假设测试前监听器已空闲、令牌桶攒满且没有其他流量消耗，那么这段时间可以消耗原有的 10 个令牌，再消耗期间新补充的约 8 个，合起来约 18 个。这个机制与截图吻合，不需要用统计误差才能解释。
令牌不足时，接入层会关闭连接，这也可以解释截图里的 EOF。持续压测应重点看启动突发结束后的平均成功速率，而不是要求从第一秒开始严格满足“经过秒数 × 10”。如果验收要求是任意滑动 1 秒都不能超过 10 个，5.8.9 的这个配置不能直接提供该保证；改写成 1/100ms 在这个版本也不会消除你这种突发。
