2. 压测基础
大家好，我是你们这堂课的老朋友。今天咱们聊聊压测最基础的东西。别觉得基础就简单，我见过太多人把压测搞成了「玄学」——跑完一堆数据，愣是看不出问题在哪。
说白了，压力测试就是模拟大量用户同时访问你的系统，看看它会不会崩。嗯，就这么简单。但真正做好它，你得先搞懂几个核心概念。
1.1 什么是压力测试？
压力测试，英文叫 Stress Testing。我个人的理解是：给系统施加超出预期的负载，观察它的行为。
举个例子。你开发了一个 AI 推理服务，平时只有 10 个人用。压测时你模拟 1000 个人同时请求。这时候系统会怎样？是变慢？是报错？还是直接挂掉？这就是压测要回答的问题。
我在项目中遇到过最典型的场景：一个模型推理服务，单机 QPS 能到 200，看着挺美。结果一上压测，并发到 500 时显存直接爆了，OOM 报错满天飞。你说这算不算坑？
1.2 压测的核心指标
搞压测，你得盯住三个指标。我管它们叫「压测三剑客」。
QPS（每秒查询数）
QPS 就是系统每秒能处理多少个请求。你想想看，一个电商网站大促时每秒要处理几万次下单，QPS 不够直接就崩了。
计算公式很简单：
QPS = 总请求数 / 总耗时（秒）举个例子：你发了 10000 个请求，花了 50 秒跑完。那 QPS 就是 200。
延迟（Latency）
延迟就是用户发一个请求到收到响应，花了多长时间。通常看三个值：
- 平均延迟：所有请求的平均耗时。容易被极端值带偏。
- P99 延迟：99% 的请求都在这个时间内完成。这个更靠谱。
- P999 延迟：千分之九十九的请求都能接受的时间。对高可用系统来说，这个值很关键。
我记得有一次压测一个 NLP 模型，平均延迟只有 50ms，看着挺好。结果一看 P99，好家伙，直接飙到 800ms。为什么？因为显存不够，部分请求被 swap 到 CPU 内存去了，速度直接掉了一个数量级。
吞吐量（Throughput）
吞吐量是系统在单位时间内能处理的数据量。对于 AI 服务来说，通常用「每秒处理的样本数」或「每秒处理的 token 数」来衡量。
举个例子：一个图像识别服务，每秒能处理 100 张图片。那它的吞吐量就是 100 images/s。
吞吐量和 QPS 有点像，但侧重点不同。QPS 关注请求数量，吞吐量关注数据量。对于大模型推理来说，吞吐量往往比 QPS 更重要。
| 指标 | 含义 | 适用场景 |
|---|---|---|
| QPS | 每秒请求数 | 通用 API 服务 |
| 延迟 | 请求响应时间 | 实时性要求高的场景 |
| 吞吐量 | 单位时间处理的数据量 | AI 推理、数据处理 |
1.3 压测工具选型
工具选对了，压测就成功了一半。我这些年用过不少工具，挑几个常用的说说。
wrk
轻量级，适合快速压测 HTTP 接口。我习惯用它做初步摸底。
wrk -t12 -c400 -d30s http://localhost:8080/api这条命令的意思是：用 12 个线程，保持 400 个并发连接，持续压 30 秒。
JMeter
功能强大，支持各种协议。我见过很多大厂都在用。它的图形界面很友好，但配置起来有点繁琐。
我个人觉得 JMeter 最大的优势是：可以模拟复杂的用户行为。比如先登录，再查询，最后提交订单。这种场景用 JMeter 做就很顺手。
Locust
基于 Python 的压测工具。代码写场景，很灵活。我最近几年用得比较多。
from locust import HttpUser, task, between
class MyUser(HttpUser):
wait_time = between(1, 5)
@task
def predict(self):
self.client.post("/predict", json={"text": "hello"})你看，代码很简洁。而且 Locust 的 Web 界面能实时看到 QPS、延迟、失败率等指标，非常直观。
- 快速摸底：用 wrk
- 复杂场景：用 JMeter
- 灵活定制：用 Locust
- AI 服务压测：我建议用 Locust + 自定义监控
1.4 知识体系总览
说了这么多，咱们用一张图来总结一下本章的核心内容。
这张图把本章的核心内容串起来了。你想想看，搞清楚了「什么是压测」，盯住了「三个核心指标」，选对了「合适的工具」，压测这件事就已经入门了。
嗯，今天就先聊到这儿。下一章咱们会深入讲讲压测的具体流程，包括怎么设计压测场景、怎么配置参数。到时候我会拿一个真实的 AI 服务案例来演示，保证干货满满。