走到这里我们已经讨论了写入、读写混合、乱序、接口、正确性、单机与集群也知道一轮结果应该怎样保存。真正开始测试时仍然可能面对一个现实问题这些原则怎样组织成一份可以执行的方案一份好的测试方案不是参数清单而是一份实验契约。它提前规定要回答的问题、唯一变量、固定条件、正确性门禁、运行矩阵和结论边界。这样无论执行者是谁最后得到的结果都在回答同一个问题。这一篇给出一份可以直接复制和裁剪的基准测试方案模板。模板中的数值和结果全部使用“待填”应根据真实业务和实际运行填写。1. 一份完整方案由什么组成业务问题硬门槛与指标环境与数据模型工作负载与变量运行矩阵预热、正式运行与重复正确性门禁归档与结论边界其中最容易被省略的是“硬门槛”和“结论边界”。如果没有预先规定什么情况下结果无效测试者很容易在看到数据后临时调整判断标准如果没有边界又容易把一个纯写结论扩展成对整个数据库的评价。2. 测试方案基本信息复制下面的表格先建立方案身份。字段内容方案名称待填方案版本待填负责人待填创建 / 更新时间待填测试目的待填被测对象待填例如数据库版本、写入接口或部署方式计划时间待填结果归档位置待填测试目的应写成可验证的问题而不是“测试一下性能”。例如在固定写入负载下新版本是否相对基线出现稳定退化在正确性通过的前提下哪一种写入接口更满足当前 P99 目标数据库从单机扩展到三节点后能否承载按计划增加的总负载3. 测试问题、假设和结论边界项目待填写内容核心问题本轮只回答什么对比对象A、B 或基线版本分别是什么唯一变量哪一个条件允许变化固定条件哪些环境、数据与负载必须一致预期现象测试前的假设是什么不覆盖范围哪些负载、部署或功能不在本轮结论内假设不是结论。它可以帮助选择指标但不能决定怎样解释结果。若实际数据不支持假设应保留原始结果并修改判断而不是调整配置直到出现想要的数字。4. 硬门槛与判断标准测试前先规定哪些结果没有资格参与比较。门槛目标或通过条件证据来源未通过如何处理正确性待填验证日志、数量核对、抽样查询结果无效先定位原因。失败率待填Benchmark 结果与日志不进入性能排名。P99待填分操作延迟矩阵标记不满足业务目标。运行完整性正常完成预热和正式阶段进程日志与时间线重跑不与完整轮次混合。客户端余量待填客户端 CPU、网络、GC增加或拆分发压端后复测。门槛应来自业务约束、SLA 或测试目标不能在看到结果后为了保留某个候选临时放宽。5. 环境清单5.1 压测客户端项目配置Benchmark 版本 / commit待填Java 版本待填客户端机器数量待填每台 CPU / 内存 / 网络待填多实例编号与设备区间待填不使用多实例则写“不适用”启动方式待填5.2 数据库服务端项目配置数据库及版本待填单机 / 集群待填节点数量与角色待填副本、分片和一致性配置待填每节点 CPU / 内存 / 磁盘 / 网络待填关键服务端参数待填数据库初始状态空库 / 固定历史数据 / 其他待填5.3 环境控制检查项约定客户端与服务端是否独占待填后台任务和定时任务待填各机器时钟同步待填缓存状态冷 / 热 / 不控制待填并说明每轮是否清库或恢复快照待填监控采样间隔待填6. 数据模型和数据规模维度配置 / 说明数据模型树模型 / 表模型 / 其他待填DEVICE_NUMBER待填SENSOR_NUMBER待填测点数据类型待填时间戳精度与间隔待填总时间范围待填标签或属性基数待填初始历史数据量待填输入数据来源与校验值待填这里记录的是逻辑数据而不是只记录最终磁盘占用。同样的数据点数如果设备基数、测点类型和时间分布不同写入与查询路径也可能完全不同。7. 工作负载定义维度配置 / 说明BENCHMARK_WORK_MODE待填OPERATION_PROPORTION待填并解释每类操作的业务含义DATA_CLIENT_NUMBER待填DEVICE_NUM_PER_WRITE待填BATCH_SIZE_PER_WRITE待填OP_MIN_INTERVAL待填INTERVAL_BETWEEN_WRITE_BATCH待填乱序比例与乱序形态待填不测试则写 0 / 不适用查询设备数与测点数待填查询时间窗口与最近数据比例待填运行停止条件总操作数 / 运行时间 / 其他待填操作比例只描述“抽到哪类操作的概率或比例”还需要把每类查询的范围、设备数、测点数和数据冷热程度写清楚。否则同样的读写比例仍可能产生完全不同的压力。8. 变量与固定项这张表是公平比较的核心。类型参数或条件取值说明唯一变量待填待填本轮主动改变的对象。固定项数据规模待填所有候选一致。固定项工作负载待填所有候选一致。固定项客户端资源待填所有候选一致。固定项服务端资源待填所有候选等价或说明差异。固定项预热和运行时长待填所有候选一致。不可避免差异待填待填说明为什么存在以及如何限制影响。不同数据库的内部参数不可能逐字相同。公平的重点是外部业务语义、可用资源和测试过程一致并公开不可避免的内部差异。9. 运行矩阵不要边跑边决定下一轮叫什么。提前给每个场景和重复轮次编号。场景编号场景候选唯一变量值预热正式运行重复次数结果状态W01顺序纯写基线A / B待填待填待填待填待测M01读写混合A / B待填待填待填待填待测O01乱序写入A / B待填待填待填待填待测C01并发扫描A / B待填待填待填待填待测B01批大小扫描A / B待填待填待填待填待测S01单机 / 集群扩展A / B待填待填待填待填待测不是每次评估都要运行整张表。应根据核心问题删除无关场景但不能在运行结束后只保留对某个候选有利的场景。10. IoT Benchmark 配置骨架下面的片段只展示方案中常用的配置入口不提供通用推荐值。使用时应以当前版本的config.properties为准并把“待填”替换为有效取值。# 被测对象 DB_SWITCH待填 BENCHMARK_WORK_MODE待填 # 数据模型与规模 DEVICE_NUMBER待填 SENSOR_NUMBER待填 # 操作与发压 OPERATION_PROPORTION待填 DATA_CLIENT_NUMBER待填 DEVICE_NUM_PER_WRITE待填 BATCH_SIZE_PER_WRITE待填 OP_MIN_INTERVAL待填 INTERVAL_BETWEEN_WRITE_BATCH待填 # 多实例测试单实例时关闭 BENCHMARK_CLUSTERfalse BENCHMARK_INDEX0 # 结果与日志 TEST_DATA_PERSISTENCECSV CSV_OUTPUTtrue REMARK待填_请勿使用特殊字符 IS_QUIET_MODEfalse LOG_PRINT_INTERVAL待填 RESULT_PRINT_INTERVAL待填实际执行前应保存一份完整配置而不是只保存这段参数摘要。完整配置可以防止某个默认值在版本间变化却未被注意。11. 标准运行流程否是冻结方案、版本和完整配置检查空库或恢复固定快照启动监控并记录时间执行预热执行正式运行保存日志、CSV 和资源数据执行正确性验证门禁通过结果标记无效并定位原因进入下一重复轮次汇总范围并写结论边界执行约定应明确每轮开始前数据库处于什么状态预热数据是否计入正式结果正式运行按时间还是操作数结束重复轮次之间是否重启、清库或等待后台任务结束多实例如何同时启动以及使用哪个公共有效时间窗口失败后是立即停止、继续记录还是重试整轮。12. 正确性门禁记录检查项预期实际证据文件结果写入成功量待填待测待填待测设备、行和点数待填待测待填待测时间戳与设备定位无差异待测待填待测类型与具体值无差异待测待填待测关键查询结果与参考结果一致待测待填待测验证错误日志无未解释错误待测待填待测只有门禁通过的轮次才进入性能统计。若工具汇总显示失败数为 0但验证日志存在值差异仍应判定正确性未通过。13. 指标与结果表13.1 客户端结果运行编号操作成功点数失败点数吞吐量平均延迟P99正确性待填待填待测待测待测待测待测待测13.2 资源结果运行编号节点CPU内存磁盘读写网络GC / 其他异常说明待填待填待测待测待测待测待测待填13.3 多轮汇总场景候选吞吐量范围P99 范围失败情况资源瓶颈是否满足目标待填待填待测待测待测待分析待判断多轮汇总优先报告范围和波动不用“最好的一次”代替稳定能力。如果轮次之间差异很大应先解释原因再决定是否增加重复次数。14. 归档清单测试结束前逐项勾选已保存本轮实际使用的完整 Benchmark 配置已记录 Benchmark、驱动和数据库不可变版本标识已保存与结论相关的服务端配置已保存完整客户端和服务端日志已保存最终 CSV 与过程测量结果已保存客户端和每个服务端节点的原始监控数据已保存正确性验证日志与预期量核对已记录预热、正式运行、异常和人工操作时间已为输入数据和关键文件生成校验值已写明结果有效性、异常和不覆盖范围。15. 结论模板最终结论可以按下面四句话组织在【环境、版本、部署】和【数据、工作负载】条件下 本轮以【唯一变量】比较了【候选对象】。 通过正确性门禁的多轮结果表明【吞吐、P99、失败与资源的实际范围】。 因此当前证据支持【选择、回归或调优判断】但不覆盖【未测试场景】。如果证据不足也可以明确写“当前轮次波动较大尚不能形成稳定排名需在固定某项条件后补测。”不下结论本身也是一种有效结论。16. 小结一份可复用的 IoT Benchmark 测试方案应把业务问题翻译为硬门槛、环境、数据模型、工作负载、唯一变量和运行矩阵再用正确性门禁、指标表和归档清单约束执行过程。模板不是为了让所有测试长得一样而是确保每个数字都有来源、每个比较都有控制变量、每个结论都有边界。系列文章第一篇数据库基准测试工具是什么第二篇从一次时序数据库写入测试开始第三篇如何模拟线上写入负载第四篇如何读懂测试结果波动第五篇什么是读写混合负载第六篇如何模拟线上读写混合负载第七篇怎样做一场公平的性能对比第八篇怎样找到并发与批大小的合理区间第九篇如何模拟乱序写入第十篇不同写入接口该怎样比较第十一篇性能测试与正确性验证有什么区别第十二篇单机测试与集群测试有什么不同第十三篇怎样保存和复盘一轮测试第十四篇一份可复用的基准测试方案模板
走到这里我们已经讨论了写入、读写混合、乱序、接口、正确性、单机与集群也知道一轮结果应该怎样保存。真正开始测试时仍然可能面对一个现实问题这些原则怎样组织成一份可以执行的方案一份好的测试方案不是参数清单而是一份实验契约。它提前规定要回答的问题、唯一变量、固定条件、正确性门禁、运行矩阵和结论边界。这样无论执行者是谁最后得到的结果都在回答同一个问题。这一篇给出一份可以直接复制和裁剪的基准测试方案模板。模板中的数值和结果全部使用“待填”应根据真实业务和实际运行填写。1. 一份完整方案由什么组成业务问题硬门槛与指标环境与数据模型工作负载与变量运行矩阵预热、正式运行与重复正确性门禁归档与结论边界其中最容易被省略的是“硬门槛”和“结论边界”。如果没有预先规定什么情况下结果无效测试者很容易在看到数据后临时调整判断标准如果没有边界又容易把一个纯写结论扩展成对整个数据库的评价。2. 测试方案基本信息复制下面的表格先建立方案身份。字段内容方案名称待填方案版本待填负责人待填创建 / 更新时间待填测试目的待填被测对象待填例如数据库版本、写入接口或部署方式计划时间待填结果归档位置待填测试目的应写成可验证的问题而不是“测试一下性能”。例如在固定写入负载下新版本是否相对基线出现稳定退化在正确性通过的前提下哪一种写入接口更满足当前 P99 目标数据库从单机扩展到三节点后能否承载按计划增加的总负载3. 测试问题、假设和结论边界项目待填写内容核心问题本轮只回答什么对比对象A、B 或基线版本分别是什么唯一变量哪一个条件允许变化固定条件哪些环境、数据与负载必须一致预期现象测试前的假设是什么不覆盖范围哪些负载、部署或功能不在本轮结论内假设不是结论。它可以帮助选择指标但不能决定怎样解释结果。若实际数据不支持假设应保留原始结果并修改判断而不是调整配置直到出现想要的数字。4. 硬门槛与判断标准测试前先规定哪些结果没有资格参与比较。门槛目标或通过条件证据来源未通过如何处理正确性待填验证日志、数量核对、抽样查询结果无效先定位原因。失败率待填Benchmark 结果与日志不进入性能排名。P99待填分操作延迟矩阵标记不满足业务目标。运行完整性正常完成预热和正式阶段进程日志与时间线重跑不与完整轮次混合。客户端余量待填客户端 CPU、网络、GC增加或拆分发压端后复测。门槛应来自业务约束、SLA 或测试目标不能在看到结果后为了保留某个候选临时放宽。5. 环境清单5.1 压测客户端项目配置Benchmark 版本 / commit待填Java 版本待填客户端机器数量待填每台 CPU / 内存 / 网络待填多实例编号与设备区间待填不使用多实例则写“不适用”启动方式待填5.2 数据库服务端项目配置数据库及版本待填单机 / 集群待填节点数量与角色待填副本、分片和一致性配置待填每节点 CPU / 内存 / 磁盘 / 网络待填关键服务端参数待填数据库初始状态空库 / 固定历史数据 / 其他待填5.3 环境控制检查项约定客户端与服务端是否独占待填后台任务和定时任务待填各机器时钟同步待填缓存状态冷 / 热 / 不控制待填并说明每轮是否清库或恢复快照待填监控采样间隔待填6. 数据模型和数据规模维度配置 / 说明数据模型树模型 / 表模型 / 其他待填DEVICE_NUMBER待填SENSOR_NUMBER待填测点数据类型待填时间戳精度与间隔待填总时间范围待填标签或属性基数待填初始历史数据量待填输入数据来源与校验值待填这里记录的是逻辑数据而不是只记录最终磁盘占用。同样的数据点数如果设备基数、测点类型和时间分布不同写入与查询路径也可能完全不同。7. 工作负载定义维度配置 / 说明BENCHMARK_WORK_MODE待填OPERATION_PROPORTION待填并解释每类操作的业务含义DATA_CLIENT_NUMBER待填DEVICE_NUM_PER_WRITE待填BATCH_SIZE_PER_WRITE待填OP_MIN_INTERVAL待填INTERVAL_BETWEEN_WRITE_BATCH待填乱序比例与乱序形态待填不测试则写 0 / 不适用查询设备数与测点数待填查询时间窗口与最近数据比例待填运行停止条件总操作数 / 运行时间 / 其他待填操作比例只描述“抽到哪类操作的概率或比例”还需要把每类查询的范围、设备数、测点数和数据冷热程度写清楚。否则同样的读写比例仍可能产生完全不同的压力。8. 变量与固定项这张表是公平比较的核心。类型参数或条件取值说明唯一变量待填待填本轮主动改变的对象。固定项数据规模待填所有候选一致。固定项工作负载待填所有候选一致。固定项客户端资源待填所有候选一致。固定项服务端资源待填所有候选等价或说明差异。固定项预热和运行时长待填所有候选一致。不可避免差异待填待填说明为什么存在以及如何限制影响。不同数据库的内部参数不可能逐字相同。公平的重点是外部业务语义、可用资源和测试过程一致并公开不可避免的内部差异。9. 运行矩阵不要边跑边决定下一轮叫什么。提前给每个场景和重复轮次编号。场景编号场景候选唯一变量值预热正式运行重复次数结果状态W01顺序纯写基线A / B待填待填待填待填待测M01读写混合A / B待填待填待填待填待测O01乱序写入A / B待填待填待填待填待测C01并发扫描A / B待填待填待填待填待测B01批大小扫描A / B待填待填待填待填待测S01单机 / 集群扩展A / B待填待填待填待填待测不是每次评估都要运行整张表。应根据核心问题删除无关场景但不能在运行结束后只保留对某个候选有利的场景。10. IoT Benchmark 配置骨架下面的片段只展示方案中常用的配置入口不提供通用推荐值。使用时应以当前版本的config.properties为准并把“待填”替换为有效取值。# 被测对象 DB_SWITCH待填 BENCHMARK_WORK_MODE待填 # 数据模型与规模 DEVICE_NUMBER待填 SENSOR_NUMBER待填 # 操作与发压 OPERATION_PROPORTION待填 DATA_CLIENT_NUMBER待填 DEVICE_NUM_PER_WRITE待填 BATCH_SIZE_PER_WRITE待填 OP_MIN_INTERVAL待填 INTERVAL_BETWEEN_WRITE_BATCH待填 # 多实例测试单实例时关闭 BENCHMARK_CLUSTERfalse BENCHMARK_INDEX0 # 结果与日志 TEST_DATA_PERSISTENCECSV CSV_OUTPUTtrue REMARK待填_请勿使用特殊字符 IS_QUIET_MODEfalse LOG_PRINT_INTERVAL待填 RESULT_PRINT_INTERVAL待填实际执行前应保存一份完整配置而不是只保存这段参数摘要。完整配置可以防止某个默认值在版本间变化却未被注意。11. 标准运行流程否是冻结方案、版本和完整配置检查空库或恢复固定快照启动监控并记录时间执行预热执行正式运行保存日志、CSV 和资源数据执行正确性验证门禁通过结果标记无效并定位原因进入下一重复轮次汇总范围并写结论边界执行约定应明确每轮开始前数据库处于什么状态预热数据是否计入正式结果正式运行按时间还是操作数结束重复轮次之间是否重启、清库或等待后台任务结束多实例如何同时启动以及使用哪个公共有效时间窗口失败后是立即停止、继续记录还是重试整轮。12. 正确性门禁记录检查项预期实际证据文件结果写入成功量待填待测待填待测设备、行和点数待填待测待填待测时间戳与设备定位无差异待测待填待测类型与具体值无差异待测待填待测关键查询结果与参考结果一致待测待填待测验证错误日志无未解释错误待测待填待测只有门禁通过的轮次才进入性能统计。若工具汇总显示失败数为 0但验证日志存在值差异仍应判定正确性未通过。13. 指标与结果表13.1 客户端结果运行编号操作成功点数失败点数吞吐量平均延迟P99正确性待填待填待测待测待测待测待测待测13.2 资源结果运行编号节点CPU内存磁盘读写网络GC / 其他异常说明待填待填待测待测待测待测待测待填13.3 多轮汇总场景候选吞吐量范围P99 范围失败情况资源瓶颈是否满足目标待填待填待测待测待测待分析待判断多轮汇总优先报告范围和波动不用“最好的一次”代替稳定能力。如果轮次之间差异很大应先解释原因再决定是否增加重复次数。14. 归档清单测试结束前逐项勾选已保存本轮实际使用的完整 Benchmark 配置已记录 Benchmark、驱动和数据库不可变版本标识已保存与结论相关的服务端配置已保存完整客户端和服务端日志已保存最终 CSV 与过程测量结果已保存客户端和每个服务端节点的原始监控数据已保存正确性验证日志与预期量核对已记录预热、正式运行、异常和人工操作时间已为输入数据和关键文件生成校验值已写明结果有效性、异常和不覆盖范围。15. 结论模板最终结论可以按下面四句话组织在【环境、版本、部署】和【数据、工作负载】条件下 本轮以【唯一变量】比较了【候选对象】。 通过正确性门禁的多轮结果表明【吞吐、P99、失败与资源的实际范围】。 因此当前证据支持【选择、回归或调优判断】但不覆盖【未测试场景】。如果证据不足也可以明确写“当前轮次波动较大尚不能形成稳定排名需在固定某项条件后补测。”不下结论本身也是一种有效结论。16. 小结一份可复用的 IoT Benchmark 测试方案应把业务问题翻译为硬门槛、环境、数据模型、工作负载、唯一变量和运行矩阵再用正确性门禁、指标表和归档清单约束执行过程。模板不是为了让所有测试长得一样而是确保每个数字都有来源、每个比较都有控制变量、每个结论都有边界。系列文章第一篇数据库基准测试工具是什么第二篇从一次时序数据库写入测试开始第三篇如何模拟线上写入负载第四篇如何读懂测试结果波动第五篇什么是读写混合负载第六篇如何模拟线上读写混合负载第七篇怎样做一场公平的性能对比第八篇怎样找到并发与批大小的合理区间第九篇如何模拟乱序写入第十篇不同写入接口该怎样比较第十一篇性能测试与正确性验证有什么区别第十二篇单机测试与集群测试有什么不同第十三篇怎样保存和复盘一轮测试第十四篇一份可复用的基准测试方案模板
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
