基准测试工具之你不知道的两三事 | 8.怎样找到并发与批大小的合理区间

上一篇文章做完公平的性能对比后，很多人会立刻追问：把客户端并发和批大小调到多大，才能得到最好的性能？

这个问题没有脱离场景的固定答案。并发过低，机器可能没有被充分利用；并发过高，客户端、网络或服务端会开始排队。批次太小，请求开销占比变大；批次太大，单次等待、内存占用和尾部延迟又可能升高。真正要找的不是一个“最大数字”，而是在当前业务约束下，吞吐量、P99、失败数和资源消耗之间的合理区间。

这一篇继续使用 IoT Benchmark，说明怎样通过受控参数扫描找到这个区间，而不是靠不断把参数调大来“跑分”。

1. 先区分：哪些参数在控制什么？

写入压力不是由单个参数决定的。IoT Benchmark 中，下面几项共同决定客户端向数据库发起请求的方式：

参数	它控制什么	容易产生的误解
DATA_CLIENT_NUMBER	负责读写数据的客户端数量	它表示测试客户端并发，不等于真实设备总数。
BATCH_SIZE_PER_WRITE	每批每个设备写入的数据行数	它改变的是批量粒度，不是设备或测点数量。
DEVICE_NUM_PER_WRITE	一个批次中写入的设备数量	它会和设备数、客户端分配方式一起影响单批数据量。
OP_MIN_INTERVAL	每个 loop 结束后的最小操作间隔	它限制的是 loop 节奏，不是每一个 batch 的间隔。
INTERVAL_BETWEEN_WRITE_BATCH	同一 loop 内每次 batch 写入后的最小间隔	它可以让写入请求在时间上分布得更均匀。

对写入而言，单批数据点规模与 DEVICE_NUM_PER_WRITE、SENSOR_NUMBER、BATCH_SIZE_PER_WRITE 共同相关。也就是说，单独提高批大小时，实际增加的并不只是“行数”，还会放大到每台设备的测点数和每批设备数。

因此，扫描参数时不要同时把所有旋钮调大。否则，即使吞吐量变化了，也不知道它来自更多客户端、更大的批次，还是更密集的发压节奏。

2. 合理区间，不是最高吞吐量对应的单点

假设不断提高 DATA_CLIENT_NUMBER：开始时，吞吐量可能上升；达到某个阶段后，增长会变慢；再继续提高时，P99 可能快速上升，甚至出现失败。这条曲线中的“最高吞吐量”不一定是业务的最佳选择。

例如，一个实时采集系统通常会更关心：在设备持续写入时，尾部延迟是否稳定、是否存在失败，以及是否给查询和其他业务预留资源。此时，吞吐量已经接近平台区、但 P99 仍平稳的一段，往往比峰值点更适合作为生产配置候选。

图中的“下一档”不需要预先规定为某个固定数值。实践中可以从较小值开始，以倍增或其他有规律的方式扩大候选范围；关键是每一档都在同一环境和同一负载下重复运行。

3. 先单因素扫描，再做小范围组合

最容易解释的做法是分两步进行。

第一步，只扫描客户端并发。固定设备数、测点数、批大小、写入间隔和乱序比例，仅改变 DATA_CLIENT_NUMBER。这样可以观察并发提升何时不再带来稳定收益。

第二步，只扫描批大小。把客户端数固定在第一步选出的候选区间内，仅改变 BATCH_SIZE_PER_WRITE。这时关注的重点从“还能否提高吞吐”变成“更大的单批请求是否开始拉高 P99 或造成失败”。

只有在这两步之后，才值得在候选区间附近进行少量组合测试。例如选取两个相邻客户端数和两个相邻批大小，形成一个小矩阵，而不是一开始就穷举所有可能值。

阶段	唯一变量	保持不变	目的
并发扫描	DATA_CLIENT_NUMBER	数据规模、批大小、间隔、乱序和环境	找到并发收益趋缓或延迟恶化的位置。
批大小扫描	BATCH_SIZE_PER_WRITE	候选客户端数、数据规模、间隔、乱序和环境	找到请求开销与单批等待之间的平衡。
小矩阵验证	客户端数与批大小的少数候选组合	数据规模、间隔、乱序和环境	验证候选区间在组合下仍稳定。

这种顺序比一次跑完整网格更省时间，也更容易说明为什么最后选择某一组配置。

4. 一份最小参数扫描配置

下面的配置只展示哪些参数通常需要被纳入扫描，不是通用性能推荐值。开始扫描前，应先把数据规模和写入负载固定下来。

# 本轮只扫描 DATA_CLIENT_NUMBER，其他值保持不变
DATA_CLIENT_NUMBER=4
BATCH_SIZE_PER_WRITE=100
DEVICE_NUM_PER_WRITE=1

# 不额外限制 loop 与 batch 的发起间隔
OP_MIN_INTERVAL=0
INTERVAL_BETWEEN_WRITE_BATCH=0

当扫描并发时，可以为每个候选值保留一条记录；当扫描批大小时，重新固定客户端数。记录表不需要复杂，重点是能回看每一轮到底改变了什么：

运行编号	唯一变量	值	吞吐量	P99	失败数	备注
concurrency-01	DATA_CLIENT_NUMBER	待填	待测	待测	待测	其余配置固定。
concurrency-02	DATA_CLIENT_NUMBER	待填	待测	待测	待测	其余配置固定。
batch-01	BATCH_SIZE_PER_WRITE	待填	待测	待测	待测	客户端数已固定。

表中的“待填”并不是结论缺失，而是提醒测试者不要在没有实际运行时先写入结果。真实测试完成后，应同时保存对应的完整配置和日志位置。

5. 怎样读出“已经到头了”？

参数扫描的结果通常会出现以下几种形态：

观察到的变化	更可能意味着什么	下一步
吞吐量持续上升，P99 与失败数稳定	当前负载下仍有余量	可以测试下一档参数。
吞吐量增幅变小，P99 仍稳定	接近吞吐平台区	在当前档与前一档之间选择更符合业务资源预算的配置。
吞吐量几乎不再提升，P99 明显升高	排队或资源争用开始显现	不再单纯加压，检查日志和资源状态。
吞吐量下降或出现失败	当前参数已超过某一环节的承受范围	回退到稳定档，定位失败原因后再测试。
不同轮次差异很大	环境、负载或系统状态尚未稳定	回到基线，确认变量是否真的被固定。

这些判断仍然需要结合服务端日志、CPU、内存、网络和存储状态。比如吞吐量平台区可能来自服务端瓶颈，也可能只是客户端无法再更快地生成或发送请求；仅看一张结果矩阵无法直接区分。

6. 给生产配置留出余量

基准测试可以把系统推到极限，生产配置却不一定应该停在极限点。现实系统还要面对查询、后台任务、网络波动、故障恢复和未来的负载增长。

因此，从扫描中选择配置时，应优先考虑下面三点：

1. 在目标业务负载下，写入和必要查询的 P99 是否仍可接受？
2. 是否连续多轮没有失败，而不是恰好有一次成功？
3. 是否还保留了应对峰值和其他业务任务的资源余量？

这也是为什么“最高吞吐量”与“最合适的生产配置”经常不是同一个答案。前者是在回答系统极限，后者是在回答系统怎样长期、稳定地服务业务。

7. 小结

并发与批大小没有放之四海皆准的最佳值。正确的做法是先固定工作负载与环境，分别扫描客户端数和批大小，记录吞吐量、P99、失败数与资源状态，再在候选区间做少量组合验证。

当吞吐量已接近平台区，而延迟、失败数和资源余量仍在业务可接受范围内，就得到了比“峰值参数”更有价值的答案。下一篇将继续讨论：怎样模拟乱序，让测试进一步接近现场数据到达方式。

系列文章

1. 第一篇：数据库基准测试工具是什么
2. 第二篇：从一次时序数据库写入测试开始
3. 第三篇：如何模拟线上写入负载
4. 第四篇：如何读懂测试结果波动
5. 第五篇：什么是读写混合负载
6. 第六篇：如何模拟线上读写混合负载
7. 第七篇：怎样做一场公平的性能对比
8. 第八篇：怎样找到并发与批大小的合理区间
9. 第九篇：如何模拟乱序写入
10. 第十篇：不同写入接口该怎样比较
11. 第十一篇：性能测试与正确性验证有什么区别
12. 第十二篇：单机测试与集群测试有什么不同
13. 第十三篇：怎样保存和复盘一轮测试
14. 第十四篇：一份可复用的基准测试方案模板