压测基础：压测目标定义、常见压测工具与指标解读

在构建尾延迟治理体系之前，必须建立扎实的压测基础。压测不是盲目施压，而是围绕明确的性能目标，使用合适的工具，对延迟分布、吞吐量和错误率进行量化评估。本节将系统梳理压测的三个核心环节：目标定义、工具选型与指标解读。

2.1 压测目标定义：从模糊到可量化

一个有效的压测目标必须满足 SMART 原则（具体、可衡量、可达成、相关、有时限）。在尾延迟场景下，目标定义需要从“系统能扛多少 QPS”升级为“在特定延迟约束下，系统能稳定承载多少负载”。

2.2 常见压测工具对比

不同的压测工具在设计哲学、协议支持和分布式能力上差异显著。以下从尾延迟压测的视角，对三款主流工具进行对比：

2.2.1 wrk：轻量级延迟探测利器

wrk 使用多线程 + 事件驱动模型，能在单机上产生极高并发。其 Lua 脚本能力允许自定义请求构造和响应处理，非常适合快速验证尾延迟基线。

# 基本用法：4 线程 100 连接，持续 30 秒
wrk -t4 -c100 -d30s --latency http://target:8080/api

# 输出示例
Latency Distribution (HdrHistogram - Recorded Latency)
 50.000%    45.12ms
 90.000%    89.34ms
 99.000%   187.65ms
 99.900%   345.21ms
 99.990%   512.89ms

2.2.2 JMeter：企业级全协议压测平台

JMeter 的图形化界面降低了脚本编写门槛，但其线程模型在超高并发下可能成为瓶颈。在尾延迟场景中，JMeter 更适合做混合协议压测和复杂业务流程的延迟验证。

# 命令行非 GUI 模式（推荐生产使用）
jmeter -n -t test_plan.jmx -l results.jtl -e -o report_dir

# 关键配置：使用 "jp@gc - Throughput Shaping Timer" 实现阶梯负载

2.2.3 Locust：Python 驱动的可编程压测

Locust 允许用纯 Python 定义用户行为，天然支持复杂的负载模型（如正弦波、脉冲波）。其 Web UI 可实时观察 RPS 和响应时间，适合需要动态调整负载的尾延迟实验。

from locust import HttpUser, task, between

class TailLatencyUser(HttpUser):
    wait_time = between(0.1, 0.5)  # 模拟随机思考时间

    @task
    def query_api(self):
        with self.client.get("/api/search", catch_response=True) as resp:
            if resp.elapsed.total_seconds() > 0.5:
                resp.failure("p99 延迟超标")
            else:
                resp.success()

2.3 压测指标深度解读

尾延迟压测的核心在于理解延迟分布而非平均值。以下指标是评估系统健康度的关键：

2.3.1 延迟指标详解

• 平均延迟 (Avg Latency)：容易被长尾请求掩盖，不适合作为尾延迟场景的决策依据。
• p50 / p90 / p99 / p99.9：分位点越高，对系统资源的敏感度越大。p99 从 100ms 上升到 500ms，往往意味着某个共享资源（如数据库连接池、线程池）已耗尽。
• 最大延迟 (Max Latency)：通常由 GC STW、网络抖动或调度延迟引起，需结合火焰图分析。
• 延迟标准差 (StdDev)：数值越大，说明系统延迟越不稳定，可能存在间歇性瓶颈。

2.3.2 吞吐量与延迟的权衡曲线

在压测中，吞吐量与延迟呈非线性关系。当系统负载超过某个阈值时，延迟会呈指数级增长，这个拐点就是系统饱和点。尾延迟治理的目标就是在饱和点之前，通过 Rate Limiting 和熔断机制，将负载控制在安全区间内。

2.4 压测流程与数据采集规范

1. 基线压测：在低负载（如 10% 预估峰值）下运行 5 分钟，记录系统空闲延迟。
2. 阶梯加压：以 20% 的步长递增负载，每个阶梯持续 3 分钟，观察延迟拐点。
3. 峰值压测：在预估峰值负载下运行 15 分钟，验证系统稳定性。
4. 过载压测：将负载提升至峰值的 120%~150%，触发 Rate Limiting 或熔断，验证保护机制是否生效。
5. 恢复测试：将负载降回基线，观察延迟和错误率是否恢复，确认系统无“雪崩后遗症”。

# 数据采集规范（每次压测必须记录）
{
  "test_id": "2025-06-15-baseline-01",
  "tool": "wrk",
  "target": "service-a:8080/api/search",
  "load_model": "fixed_concurrency",
  "concurrency": 100,
  "duration_sec": 180,
  "results": {
    "avg_latency_ms": 42.3,
    "p50_ms": 38.1,
    "p90_ms": 72.5,
    "p99_ms": 156.8,
    "p99.9_ms": 312.4,
    "max_latency_ms": 589.2,
    "rps": 2340,
    "error_rate_pct": 0.02,
    "timeout_rate_pct": 0.01
  },
  "system_metrics": {
    "cpu_pct": 65,
    "mem_gb": 4.2,
    "gc_pause_max_ms": 45
  }
}