上一篇文章做完公平的性能对比后很多人会立刻追问把客户端并发和批大小调到多大才能得到最好的性能这个问题没有脱离场景的固定答案。并发过低机器可能没有被充分利用并发过高客户端、网络或服务端会开始排队。批次太小请求开销占比变大批次太大单次等待、内存占用和尾部延迟又可能升高。真正要找的不是一个“最大数字”而是在当前业务约束下吞吐量、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共同相关。也就是说单独提高批大小时实际增加的并不只是“行数”还会放大到每台设备的测点数和每批设备数。DATA_CLIENT_NUMBER并发请求形态DEVICE_NUM_PER_WRITE单批设备数SENSOR_NUMBER单批数据点规模BATCH_SIZE_PER_WRITE吞吐量、P99、失败数操作与批次间隔因此扫描参数时不要同时把所有旋钮调大。否则即使吞吐量变化了也不知道它来自更多客户端、更大的批次还是更密集的发压节奏。2. 合理区间不是最高吞吐量对应的单点假设不断提高DATA_CLIENT_NUMBER开始时吞吐量可能上升达到某个阶段后增长会变慢再继续提高时P99 可能快速上升甚至出现失败。这条曲线中的“最高吞吐量”不一定是业务的最佳选择。例如一个实时采集系统通常会更关心在设备持续写入时尾部延迟是否稳定、是否存在失败以及是否给查询和其他业务预留资源。此时吞吐量已经接近平台区、但 P99 仍平稳的一段往往比峰值点更适合作为生产配置候选。是否否是选择一个参数固定其余配置从低到高扫描记录吞吐量、P99、失败数与资源状态吞吐量仍明显提升继续增加下一档P99 或失败数是否恶化得到候选合理区间回退到前一档并复测图中的“下一档”不需要预先规定为某个固定数值。实践中可以从较小值开始以倍增或其他有规律的方式扩大候选范围关键是每一档都在同一环境和同一负载下重复运行。3. 先单因素扫描再做小范围组合最容易解释的做法是分两步进行。第一步只扫描客户端并发。固定设备数、测点数、批大小、写入间隔和乱序比例仅改变DATA_CLIENT_NUMBER。这样可以观察并发提升何时不再带来稳定收益。第二步只扫描批大小。把客户端数固定在第一步选出的候选区间内仅改变BATCH_SIZE_PER_WRITE。这时关注的重点从“还能否提高吞吐”变成“更大的单批请求是否开始拉高 P99 或造成失败”。只有在这两步之后才值得在候选区间附近进行少量组合测试。例如选取两个相邻客户端数和两个相邻批大小形成一个小矩阵而不是一开始就穷举所有可能值。阶段唯一变量保持不变目的并发扫描DATA_CLIENT_NUMBER数据规模、批大小、间隔、乱序和环境找到并发收益趋缓或延迟恶化的位置。批大小扫描BATCH_SIZE_PER_WRITE候选客户端数、数据规模、间隔、乱序和环境找到请求开销与单批等待之间的平衡。小矩阵验证客户端数与批大小的少数候选组合数据规模、间隔、乱序和环境验证候选区间在组合下仍稳定。这种顺序比一次跑完整网格更省时间也更容易说明为什么最后选择某一组配置。4. 一份最小参数扫描配置下面的配置只展示哪些参数通常需要被纳入扫描不是通用性能推荐值。开始扫描前应先把数据规模和写入负载固定下来。# 本轮只扫描 DATA_CLIENT_NUMBER其他值保持不变 DATA_CLIENT_NUMBER4 BATCH_SIZE_PER_WRITE100 DEVICE_NUM_PER_WRITE1 # 不额外限制 loop 与 batch 的发起间隔 OP_MIN_INTERVAL0 INTERVAL_BETWEEN_WRITE_BATCH0当扫描并发时可以为每个候选值保留一条记录当扫描批大小时重新固定客户端数。记录表不需要复杂重点是能回看每一轮到底改变了什么运行编号唯一变量值吞吐量P99失败数备注concurrency-01DATA_CLIENT_NUMBER待填待测待测待测其余配置固定。concurrency-02DATA_CLIENT_NUMBER待填待测待测待测其余配置固定。batch-01BATCH_SIZE_PER_WRITE待填待测待测待测客户端数已固定。表中的“待填”并不是结论缺失而是提醒测试者不要在没有实际运行时先写入结果。真实测试完成后应同时保存对应的完整配置和日志位置。5. 怎样读出“已经到头了”参数扫描的结果通常会出现以下几种形态观察到的变化更可能意味着什么下一步吞吐量持续上升P99 与失败数稳定当前负载下仍有余量可以测试下一档参数。吞吐量增幅变小P99 仍稳定接近吞吐平台区在当前档与前一档之间选择更符合业务资源预算的配置。吞吐量几乎不再提升P99 明显升高排队或资源争用开始显现不再单纯加压检查日志和资源状态。吞吐量下降或出现失败当前参数已超过某一环节的承受范围回退到稳定档定位失败原因后再测试。不同轮次差异很大环境、负载或系统状态尚未稳定回到基线确认变量是否真的被固定。这些判断仍然需要结合服务端日志、CPU、内存、网络和存储状态。比如吞吐量平台区可能来自服务端瓶颈也可能只是客户端无法再更快地生成或发送请求仅看一张结果矩阵无法直接区分。6. 给生产配置留出余量基准测试可以把系统推到极限生产配置却不一定应该停在极限点。现实系统还要面对查询、后台任务、网络波动、故障恢复和未来的负载增长。因此从扫描中选择配置时应优先考虑下面三点在目标业务负载下写入和必要查询的 P99 是否仍可接受是否连续多轮没有失败而不是恰好有一次成功是否还保留了应对峰值和其他业务任务的资源余量这也是为什么“最高吞吐量”与“最合适的生产配置”经常不是同一个答案。前者是在回答系统极限后者是在回答系统怎样长期、稳定地服务业务。7. 小结并发与批大小没有放之四海皆准的最佳值。正确的做法是先固定工作负载与环境分别扫描客户端数和批大小记录吞吐量、P99、失败数与资源状态再在候选区间做少量组合验证。当吞吐量已接近平台区而延迟、失败数和资源余量仍在业务可接受范围内就得到了比“峰值参数”更有价值的答案。下一篇将继续讨论怎样模拟乱序、补传与高峰写入让测试进一步接近现场数据到达方式。系列文章第一篇数据库基准测试工具是什么第二篇从一次时序数据库写入测试开始第三篇如何模拟线上写入负载第四篇如何读懂测试结果波动第五篇什么是读写混合负载第六篇如何模拟线上读写混合负载第七篇怎样做一场公平的性能对比