性能测试结果分析实战——TPS、响应时间、错误率、百分位数深度解读

老张2026/4/30大约 8 分钟

性能测试结果分析实战——TPS、响应时间、错误率、百分位数深度解读

适读人群：后端工程师、测试工程师、技术管理者 | 阅读时长：约14分钟 | 核心价值：学会正确解读压测数据，不被平均值迷惑，从数据中找到真正的性能问题

一份漂亮的报告，掩盖了一个严重的问题

2021年某次大促压测，同事提交了一份报告：平均响应时间185ms，TPS 1250，错误率0。结论：性能优秀，系统就绪。

我看了眼数据说："你把P999给我看看。"

他加出来一看：P999是14300ms。

这意味着每1000个用户里，有1个人等了14秒多。在大促当天每秒1000个请求的场景下，每秒就有1个用户遇到14秒的超时。累计1小时，3600个用户等了14秒以上。

他的报告里只有平均值，这个严重的问题完全被掩盖了。

平均值是性能分析里最危险的指标。 它掩盖了真实的用户体验分布。

TPS（吞吐量）正确解读

TPS（Transactions Per Second）是系统每秒处理的请求数，是最直观的吞吐量指标。

几个关于TPS的常见误区

误区1：TPS越高越好

TPS高不一定是好事。如果你的接口应该返回200但全返回了404（错误响应），TPS会很高，P99也很低——因为错误响应的处理比正常响应快得多。

正确做法：TPS必须和错误率一起看。有效TPS = 总TPS × (1 - 错误率)。

误区2：TPS等于QPS

TPS是事务级别的，一个事务可能包含多个HTTP请求（比如登录+查询+下单算一个事务）。QPS是请求级别的，是每秒的HTTP请求数。通常QPS ≥ TPS。

说清楚你说的是哪个，避免混淆。

误区3：单看TPS数字

TPS数字必须结合并发数和响应时间一起分析：

理论关系：TPS = 并发用户数 / 平均响应时间（秒）

例：
- 200并发，平均响应200ms → TPS ≈ 1000
- 200并发，平均响应100ms → TPS ≈ 2000
- 200并发，平均响应400ms → TPS ≈ 500

当TPS < 并发/响应时间，说明有系统资源竞争或等待

TPS曲线形态分析

稳定型（理想）：TPS曲线平稳，波动小于5%

下降型（问题）：TPS随时间缓慢下降，说明系统有资源耗尽（连接池、内存）在发生

锯齿型（需要关注）：TPS周期性波动，每次波谷可能对应GC暂停或定时任务执行

崩溃型（严重问题）：TPS在某个时间点突然降到极低，说明发生了雪崩（级联故障、OOM等）

响应时间指标深度解读

为什么不能只看平均值

用一个极端例子说明：

10个请求的响应时间（ms）：
10, 12, 11, 13, 10, 12, 11, 10, 9, 5000

平均值：(10+12+11+13+10+12+11+10+9+5000) / 10 = 509.8ms
中位数（P50）：11ms
P90：13ms
P99：5000ms（样本太少，这里等于最大值）

平均值509ms，看起来很糟糕。但实际上90%的请求都在13ms内完成，只有一个极慢的请求把平均值拉高了。

反过来也成立：平均值很好，但如果P99很高，说明有一小撮用户在体验极差的服务。

百分位数含义

P50（中位数）= 50%的请求在这个时间内完成
P75         = 75%的请求在这个时间内完成
P90         = 90%的请求在这个时间内完成
P95         = 95%的请求在这个时间内完成
P99         = 99%的请求在这个时间内完成
P999        = 99.9%的请求在这个时间内完成

哪个指标最重要？

取决于你的业务场景：

用户体验类接口（搜索、商品详情）：P99最重要。99%的用户体验要保证
核心交易类接口（下单、支付）：P99+P999都要看。那1/1000的超时可能造成资金风险
内部调用/后台任务：P95够了，不需要过度优化尾部

SLA通常的定义方式：

接口级SLA：P99 < 500ms，错误率 < 0.1%
服务级SLA：P99 < 1000ms，可用性 > 99.9%

响应时间的各个阶段拆解

一个HTTP请求的响应时间包括多个阶段，JMeter/k6都可以分别统计：

总响应时间 = DNS解析 + TCP建连 + TLS握手 + 发送请求 + 等待响应 + 接收响应

k6的timings对象：
- timings.blocked    = 等待可用连接的时间（可能被连接池阻塞）
- timings.connecting = TCP建连时间
- timings.tls_handshaking = TLS握手时间
- timings.sending    = 发送请求数据时间
- timings.waiting    = 服务器处理时间（TTFB，Time To First Byte）
- timings.receiving  = 接收响应时间
- timings.duration   = 总时间

如果timings.waiting很高，说明服务器处理慢；如果timings.blocked很高，说明连接池是瓶颈；如果timings.connecting很高，说明网络或服务器建连有问题。

错误率解读

错误率看起来很简单，但有几个细节需要注意。

什么算"错误"

默认情况下，JMeter和k6都把HTTP状态码非2xx的响应算作错误。但这在某些场景下是不够的：

返回了HTTP 200，但业务code是500（{"code":500,"msg":"系统繁忙"}）→ 这是业务错误，必须用断言捕获
返回了HTTP 200，但响应时间超过了SLA → 也可以算作"超时错误"

正确的错误率统计必须包括：

HTTP状态码错误（4xx/5xx）
业务code错误（通过断言）
响应时间超阈值错误（通过Duration Assertion）
连接超时/读取超时

错误率的告警阈值

不同场景的容忍度不同：

场景	可接受错误率
正常业务流量	< 0.01%
大促高峰期	< 0.1%
压力测试极限点	< 1%
稳定性测试	< 0.05%

错误率异常时的排查思路

错误率突然升高
    ↓
看错误响应内容
    ├── 503 Service Unavailable → 下游服务不可用，看依赖服务监控
    ├── 504 Gateway Timeout → 超时，看是哪一层超时
    ├── 500 Internal Server Error → 应用异常，看应用日志
    ├── 429 Too Many Requests → 限流，看是否触发了限流规则
    └── 业务错误（code非0） → 看业务逻辑，可能是数据冲突

用 Python 分析 JTL 文件

JMeter输出的JTL文件是CSV格式，可以用Python做深度分析：

import pandas as pd
import numpy as np
import matplotlib.pyplot as plt
import matplotlib
matplotlib.use('Agg')

def analyze_jtl(jtl_path: str, output_dir: str = '/tmp'):
    """
    分析JMeter JTL文件，生成完整的性能报告
    """
    # 读取JTL
    df = pd.read_csv(jtl_path)
    
    # 标准JTL列名
    # timeStamp, elapsed, label, responseCode, responseMessage, 
    # threadName, success, failureMessage, bytes, sentBytes, 
    # grpThreads, allThreads, Latency, IdleTime, Connect
    
    print(f"总请求数: {len(df)}")
    print(f"时间范围: {pd.to_datetime(df['timeStamp'], unit='ms').min()} ~ "
          f"{pd.to_datetime(df['timeStamp'], unit='ms').max()}")
    
    # 计算时间范围
    start_ts = df['timeStamp'].min()
    end_ts = df['timeStamp'].max()
    duration_sec = (end_ts - start_ts) / 1000
    
    # 按接口分组分析
    for label, group in df.groupby('label'):
        elapsed = group['elapsed'].values
        total = len(elapsed)
        errors = total - group['success'].sum()
        error_rate = errors / total * 100
        
        # 计算百分位数
        percentiles = np.percentile(elapsed, [50, 75, 90, 95, 99, 99.9])
        
        # 计算TPS
        tps = total / duration_sec
        
        print(f"\n{'='*50}")
        print(f"接口: {label}")
        print(f"总请求: {total:,}")
        print(f"错误数: {int(errors)} ({error_rate:.3f}%)")
        print(f"TPS: {tps:.1f}")
        print(f"P50: {percentiles[0]:.0f}ms")
        print(f"P75: {percentiles[1]:.0f}ms")
        print(f"P90: {percentiles[2]:.0f}ms")
        print(f"P95: {percentiles[3]:.0f}ms")
        print(f"P99: {percentiles[4]:.0f}ms")
        print(f"P999: {percentiles[5]:.0f}ms")
        print(f"最大值: {elapsed.max()}ms")
        print(f"最小值: {elapsed.min()}ms")
    
    # 绘制P99时间序列图
    df['second'] = (df['timeStamp'] - start_ts) // 1000
    p99_by_second = df.groupby('second')['elapsed'].quantile(0.99)
    tps_by_second = df.groupby('second').size()
    
    fig, (ax1, ax2) = plt.subplots(2, 1, figsize=(14, 8))
    
    ax1.plot(p99_by_second.index, p99_by_second.values, color='#E64A19', linewidth=1.5)
    ax1.set_title('P99 Response Time Over Time')
    ax1.set_ylabel('P99 (ms)')
    ax1.set_xlabel('Time (seconds)')
    ax1.axhline(y=500, color='red', linestyle='--', alpha=0.7, label='500ms threshold')
    ax1.legend()
    ax1.grid(True, alpha=0.3)
    
    ax2.plot(tps_by_second.index, tps_by_second.values, color='#1976D2', linewidth=1.5)
    ax2.set_title('Requests Per Second (TPS)')
    ax2.set_ylabel('RPS')
    ax2.set_xlabel('Time (seconds)')
    ax2.grid(True, alpha=0.3)
    
    plt.tight_layout()
    plt.savefig(f'{output_dir}/performance_report.png', dpi=150)
    print(f"\n报告图表已保存: {output_dir}/performance_report.png")

if __name__ == '__main__':
    analyze_jtl('/tmp/results/result.jtl', '/tmp/results')