基准测试工具之你不知道的两三事 | 如何模拟线上写入负载上一篇文章里我们已经跑通了一次 IoT Benchmark 的默认写入测试并学会了从吞吐量、失败数和 P99 延迟中读出一轮测试的基本情况。不过默认配置只能证明工具能够运行不能自动代表你的业务。现实中的设备有多少每个设备有多少测点数据是稳定上报还是集中补传一条请求会写入多少行这些问题不先回答再精确的测试也只是在测一份陌生的负载。这一篇继续使用 IoT Benchmark讨论写入工作负载怎样把业务中的设备、上报节奏和补传行为翻译成一份可执行、可解释的配置。1. 工作负载不是“把参数调大”很多人第一次调基准测试会先想到把设备数、并发数和循环次数都调大。这样做当然可能把系统压到更高负载但它回答的往往只是“在这组极限参数下能跑多快”而不是“在我的业务里会怎样”。写入工作负载设计的核心不是制造一个最大的数字而是让测试里的写入行为和业务里的上报行为能一一对应。它至少应说明四件事谁在产生数据设备数量、每台设备的测点数量以及是否所有设备都持续上报。数据怎样到达时间戳间隔、写入批次、客户端并发以及是否存在补传或乱序。写入的形态是什么所有设备平稳上报还是多个网关批量发送是否有高峰或集中补传。这轮测试想回答什么验证持续写入能力、比较版本、观察尾部延迟还是检查乱序数据下的稳定性。当这四件事说清楚后配置文件才不再是一张参数清单而是一份可以讨论的“业务假设”。业务写入描述设备与测点规模上报节奏与补传IoT Benchmark 参数配置单变量运行吞吐量、P99 与失败数判断写入能力与瓶颈这条链路的关键在于结果必须能追溯到前面的业务假设而不是只保留最后一列性能数字。2. 先明确一句业务描述在打开config.properties之前不妨先用一句自然语言写下本轮测试的目标。例如模拟 500 台冷链设备每台上报 12 个测点每分钟一次网络恢复后可能集中补传一小部分历史数据。这句话还不够精确却已经给出了工作负载最重要的骨架。接下来只需要把它拆成 IoT Benchmark 能理解的几个维度。业务描述常用参数需要想清楚的事有多少实体和指标DEVICE_NUMBER、SENSOR_NUMBER一台设备对应一个逻辑实体吗不同设备的测点数量是否相同哪些设备真的在写REAL_INSERT_RATE是所有设备持续上报还是只有部分设备在当前时段活跃数据的逻辑时间间隔POINT_STEP、START_TIME相邻数据点在业务时间上相隔多久请求到达的节奏OP_MIN_INTERVAL、DATA_CLIENT_NUMBER、BATCH_SIZE_PER_WRITE数据是平稳到达还是由多个客户端批量发送写入操作的构成OPERATION_PROPORTION本轮是否保持纯写负载避免查询干扰写入基线是否有迟到数据IS_OUT_OF_ORDER、OUT_OF_ORDER_RATIO现场断网、边缘缓存回传等情况是否会造成乱序表中的参数不是每一轮都要修改。它的作用是提醒我们每改一个参数都应能说出它对应哪一种业务行为。3. 三个容易混淆的“速度”时序测试中常常同时出现时间间隔、客户端并发和吞吐量它们看起来都和“快慢”有关实际回答的却不是同一个问题。POINT_STEP表示生成数据的相邻时间戳间隔。把它设置为60000表达的是相邻数据点在业务时间上相隔一分钟它并不等于工具会每分钟才发出一次请求。OP_MIN_INTERVAL才与客户端操作之间的最小间隔有关。当前配置说明中0表示不限制-1表示让该间隔与POINT_STEP相同。它可以帮助我们把持续写入的节奏做得更接近周期性上报而不是让客户端尽可能快地把数据全部灌入。DATA_CLIENT_NUMBER和BATCH_SIZE_PER_WRITE则描述客户端怎样组织写入请求前者控制参与写入的数据客户端数量后者控制每批每个设备写入的数据行数。它们通常影响服务端看到的并发和批量大小但不应被直接理解成“真实设备数量”。可以把三者简单地区分为POINT_STEP 数据在业务时间轴上的间隔 OP_MIN_INTERVAL 客户端尝试发起操作的节奏 DATA_CLIENT_NUMBER/BATCH_SIZE_PER_WRITE 客户端组织并发与批量的方式把这三层混为一谈是很多“测试结果看起来很高、却不像真实业务”的根源。4. 从一句话到第一份配置仍以前面的冷链设备为例。若这一轮只想先确认周期性写入的基线可以先写成一份纯写负载# 规模500 台设备每台 12 个测点 DEVICE_NUMBER500 SENSOR_NUMBER12 REAL_INSERT_RATE1.0 # 写入组织4 个数据客户端每个批次写入 100 行 DATA_CLIENT_NUMBER4 BATCH_SIZE_PER_WRITE100 # 业务时间每分钟一个数据点操作节奏跟随该时间间隔 POINT_STEP60000 OP_MIN_INTERVAL-1 # 本轮只测写入不加入查询与乱序 OPERATION_PROPORTION1:0:0:0:0:0:0:0:0:0:0:0:0 IS_OUT_OF_ORDERfalse这不是一份“冷链行业标准配置”也不意味着每分钟上报的设备必须这样写入。它只是把前面的业务描述明确成了一组可执行假设500 台设备全部活跃写入为主没有迟到数据客户端按固定节奏组织请求。得到第一份配置后最重要的动作不是立刻把并发拉高而是确认它能否被业务同事和自己几周后的复查所解释。比如现场设备是否真的全部在线设备是逐台上报还是网关会把多台设备的数据合并发送如果答案不同配置也应随之调整。5. 不要忽略乱序、峰值与批写实验室中的数据常常按时间顺序写入生产现场却未必如此。网络中断、边缘缓存、批量补传都会让旧时间戳的数据晚于新数据到达。IoT Benchmark 通过IS_OUT_OF_ORDER开关乱序写入并通过OUT_OF_ORDER_RATIO描述乱序数据所占的比例。是否开启乱序不该由“这样测试更难”决定而应由业务是否确实存在迟到数据决定。一个合理的做法是把它单独设计成一轮测试先记录全顺序写入的基线再固定其余参数只开启乱序并逐步调整比例。这样才能看清乱序到底带来了多少影响。除了乱序写入负载还常常有两种容易被默认配置忽略的形态突发上报和批量导入。前者可能来自大量设备在整点同时上报后者可能来自历史数据迁移或网关长时间离线后的集中回传。它们不能只靠“调高并发”草率模拟而要先定义峰值来自多少客户端、持续多久、每次请求带来多少行数据。无论测试哪一种写入形态都应让本轮问题和配置一一对应本轮问题更合适的负载思路新版本写入是否退化固定数据规模和环境使用纯写负载。断网补传是否拖慢在线写入保持其余条件不变单独开启乱序并调整其比例。数据库是否能承受整点上报固定设备规模定义峰值客户端数、批大小与持续时间再逐步提高写入压力。历史数据导入是否稳定保持写入操作不变逐步扩大批大小或总循环次数并记录失败数和尾部延迟。6. 一次测试只回答一个问题好的基准测试不一定参数很多但必须有清楚的对照关系。假设我们想研究批大小的影响可以让设备数、测点数、客户端数、时间间隔、数据库版本和硬件环境保持不变只测试BATCH_SIZE_PER_WRITE的几组值。这样吞吐量或 P99 的变化才有明确归因。反过来若一次同时改变设备数、客户端数、批大小、乱序比例和上报节奏即使得到一张漂亮的结果表也很难判断究竟是哪一个因素造成差异。基准测试最常见的陷阱不是数据不够多而是变量不够少。在每轮开始前可以给配置文件旁边补上三行说明问题本轮想验证什么 变量本轮只改变哪个参数 保持不变环境、数据库版本、其余工作负载参数有哪些这三行字不会让系统跑得更快却能让结果更有解释力。7. 小结用 IoT Benchmark 设计写入工作负载并不是从参数表中挑几个看起来“够大”的值而是把真实业务中的设备、上报节奏、批写和迟到数据逐步翻译成可复现的配置。一份起步阶段的好配置至少要回答下面几个问题设备和测点规模来自什么业务事实逻辑时间间隔、实际发压节奏和客户端并发是否被区分开本轮是否需要模拟乱序、补传、突发上报或批量导入这轮测试只改变了什么又固定了什么结果能否回溯到完整的配置、环境和日志当工作负载有了这样的来路吞吐量和延迟才不再只是终端里的一串数字而能帮助我们判断数据库是否真正适合某个具体场景。下一篇我们将继续讨论同一套负载跑出多次不同结果时怎样读懂波动、定位瓶颈并避免得出过早的结论。系列文章第一篇数据库基准测试工具是什么第二篇从一次时序数据库写入测试开始