4. 压测数据基础：性能压测的核心指标与数据采集

性能压测是云原生灾备准入策略与容量基线校准的数据基石。只有准确理解并采集核心指标，才能将压测数据有效转化为准入决策依据。本节将系统梳理压测的四大核心指标及其采集存储方法。

4.1 核心指标定义与关系

性能压测的四大核心指标——TPS、QPS、响应时间、并发数——共同构成了系统性能的完整画像。它们之间存在明确的数学与逻辑关系，理解这些关系是进行容量评估的前提。

指标	英文全称	定义	典型单位	云原生场景关注点
TPS	Transactions Per Second	系统每秒处理的事务数（一个事务可能包含多个请求）	tps	数据库写入、订单提交、支付完成等完整业务操作
QPS	Queries Per Second	系统每秒处理的查询或请求数（通常指单一接口调用）	qps	API 网关、微服务接口、缓存查询、静态资源请求
响应时间	Response Time / Latency	从发送请求到收到完整响应所经过的时间	ms / s	P50、P95、P99 分位值，尤其关注长尾延迟
并发数	Concurrency / VUsers	同一时刻系统正在处理的请求或事务数量	个	Pod 副本数、连接池大小、线程池配置

4.2 指标采集架构与工具链

在云原生环境中，压测数据的采集需要覆盖从客户端到服务端、从基础设施到业务逻辑的全链路。下图展示了典型的压测数据采集架构。

4.3 指标存储策略与数据生命周期

压测数据具有高写入、高时效、多维度的特点，存储策略直接影响后续分析的效率与成本。下表对比了不同存储方案的适用场景。

存储类型	典型产品	适用数据	保留周期	查询模式
时序数据库	VictoriaMetrics, Thanos	TPS、QPS、响应时间、CPU/内存利用率	30~90 天（热数据）	实时监控、趋势分析、告警
对象存储	MinIO, AWS S3	原始压测日志、全量请求明细	6~12 个月（冷数据）	离线分析、审计回溯、模型训练
关系数据库	PostgreSQL, MySQL	压测任务元数据、配置参数、准入结果	长期（永久）	任务管理、报表查询、合规审计

4.4 数据采集的常见陷阱与避坑指南

• 采样周期不一致： 压测工具（如 JMeter）默认 1 秒聚合一次，而 Prometheus 默认 15 秒抓取一次，导致数据对齐困难。建议统一采样周期为 5 秒或 10 秒。
• 响应时间分位值缺失： 仅采集平均响应时间会掩盖长尾问题。必须采集 P50、P95、P99 分位值，并在存储时保留原始分布直方图。
• 并发数定义混淆： 压测工具报告的“并发数”通常是虚拟用户数（VUsers），而非系统实际处理的并发请求数。应使用 rate(http_requests_total[1m]) * histogram_quantile(0.99, ...) 计算真实并发。
• 忽略冷启动与 JIT 预热： 云原生应用（尤其是 Java/Go 服务）在启动初期性能不稳定。压测数据应丢弃前 30~60 秒的“预热期”数据，只采集稳态数据。

4.5 数据驱动的准入决策流程

采集并存储压测数据后，需要将其转化为可执行的准入决策。下图展示了从原始数据到准入结论的完整链路。