2. 性能测试基础概念回顾：吞吐量、响应时间、并发用户数、TPS、QPS、P99延迟
在深入因子低延迟评分接口的性能测试之前，必须统一团队对核心度量指标的理解。这些指标构成了性能分析与瓶颈定位的“通用语言”。以下逐一拆解其定义、计算方式与典型关系。
2.1 核心指标定义与对比
| 指标 | 英文全称 | 定义 | 典型单位 | 适用场景 |
|---|---|---|---|---|
| 吞吐量 | Throughput | 单位时间内系统成功处理并输出的数据量或请求数 | 请求/秒、MB/s | 衡量系统整体处理能力 |
| 响应时间 | Response Time | 从客户端发出请求到收到完整响应的总耗时 | 毫秒 (ms) | 用户体验的直接反映 |
| 并发用户数 | Concurrent Users | 同一时间点（窗口）内，与系统保持交互的用户数量 | 个 | 容量规划与负载模型设计 |
| TPS | Transactions Per Second | 每秒完成的事务数（事务通常指一个完整的业务操作） | tps | 复杂业务链路（如评分+入库+回调） |
| QPS | Queries Per Second | 每秒完成的查询或请求数（侧重单次请求） | qps | 简单查询接口、读密集型服务 |
| P99延迟 | 99th Percentile Latency | 排序后，处于第99百分位的响应时间（即99%的请求快于此值） | 毫秒 (ms) | 长尾延迟监控、SLA/SLO 定义 |
低延迟场景提示： 对于因子评分接口，P99延迟 比平均延迟更重要。平均延迟可能掩盖少量极慢请求，而 P99 能直接反映最差情况下的用户体验，是评分接口 SLA 的核心指标。
2.2 指标关系与经典公式
这些指标并非孤立存在，它们通过 Little's Law 和 排队论 相互关联。理解其关系是进行容量预估和瓶颈分析的基础。
- Little's Law： 并发用户数 = 吞吐量 × 平均响应时间 (N = X × R)。
- TPS 与 QPS 的关系： 一个事务可能包含多个查询。例如，一次评分事务可能包含 3 次数据库查询，则 TPS = QPS / 3（在理想流水线模式下）。
- 响应时间与吞吐量的权衡： 在系统达到饱和点之前，吞吐量增加通常伴随响应时间小幅上升；超过饱和点后，响应时间会急剧恶化。
关键公式： 并发用户数 (N) = TPS × 平均响应时间 (秒)。例如，目标 TPS=1000，平均响应时间=50ms (0.05s)，则所需并发用户数 = 1000 × 0.05 = 50。
2.3 性能指标关系图
下图展示了在负载递增过程中，吞吐量与响应时间、并发用户数之间的典型演变关系，帮助理解“拐点”与“饱和区”。
2.4 P99 延迟与长尾效应
P99 延迟是低延迟评分接口最关键的监控指标之一。它揭示了“长尾”请求对系统稳定性的影响。
- 定义： 将 1000 个请求的响应时间从小到大排序，第 990 个请求的响应时间即为 P99。它表示只有 1% 的请求比这个值更慢。
- 为什么关注 P99： 平均延迟可能为 10ms，但 P99 可能高达 200ms。这意味着每 100 个用户中，就有 1 个用户感受到明显的卡顿。对于金融级评分接口，这种抖动不可接受。
- 常见原因： GC 暂停、缓存未命中、网络抖动、资源争抢（锁、连接池耗尽）。
避坑指南： 不要仅优化平均延迟。在低延迟系统中，应同时设定 P99 和 P999 目标。例如：P99 ≤ 50ms，P999 ≤ 200ms。忽略长尾优化，会导致系统在极端流量下出现雪崩。
2.5 指标在评分接口中的映射
将上述通用指标映射到“因子低延迟评分接口”的具体场景中，有助于设计更有针对性的测试用例。
| 通用指标 | 评分接口映射 | 测试关注点 |
|---|---|---|
| TPS | 每秒完成的评分请求数（一次评分 = 一个事务） | 接口能否支撑业务峰值 TPS（如双十一大促） |
| 响应时间 | 从发送评分请求到收到评分结果的总耗时 | 端到端延迟是否满足业务 SLA（如 < 30ms） |
| 并发用户数 | 同时发起评分请求的客户端线程数 | 模拟真实并发场景，验证线程池与连接池配置 |
| P99延迟 | 99% 的评分请求在多少毫秒内完成 | 长尾请求是否触发超时或熔断 |
| 吞吐量 | 单位时间内成功返回评分结果的请求总量 | 系统最大处理能力，用于容量规划 |
2.6 指标采集与计算逻辑
在性能测试工具（如 JMeter、Locust、wrk）中，这些指标通常通过以下方式采集：
// 伪代码：P99 延迟计算逻辑
List<Long> latencies = getAllResponseTimes(); // 获取所有请求的响应时间
Collections.sort(latencies); // 升序排序
int index = (int) Math.ceil(99.0 / 100.0 * latencies.size()) - 1;
long p99Latency = latencies.get(index); // 取第 99% 位置的元素
// 吞吐量计算
long totalRequests = getTotalSuccessRequests();
long testDurationSeconds = getTestDurationInSeconds();
double throughput = (double) totalRequests / testDurationSeconds;
工具建议： 使用 JMeter 的聚合报告 或 Grafana + Prometheus 实时监控 P99 延迟。对于低延迟接口（< 10ms），注意工具本身的采样精度，建议使用 异步非阻塞 的压测工具（如 wrk2）以减少客户端侧的开销干扰。
2.7 指标关系总结图
下图总结了各指标之间的逻辑关系与数据流向，帮助建立全局视角。