ELI5 · 说人话
把你的服务想成一家小饭馆。
这四个词全在数同一件事的不同侧面：
来多少人、手上压着几单、多久做完、一秒出几份。
先认人
Queries Per Second
QPS · 每秒请求数
一秒钟收进来多少张条子。数的是动作。一次翻页、一次搜索、一次心跳检查，都算一个。
饭馆里：后厨这一秒接了 500 张单。
Transactions Per Second
TPS · 每秒事务数
一秒钟做成多少笔完整的生意。下单、支付、转账——从头到尾走完才算一笔，中途失败不算。
饭馆里：这一秒真正端出去 100 份餐。
Response Time
RT · 响应时间
一位客人从下单到拿到餐等了多久。四个数里只有它是用户真能感觉到的。
饭馆里：这一趟 0.3 秒 = 300ms。
Concurrency
并发数 · 同时在途
此时此刻手上有几单还没做完。它是快照，不是速率——另外三个都是「每秒多少」，只有它数的是当下那一堆。
饭馆里：这一瞬间 150 个人还没吃上。
最常混的一对
用户点一次「提交订单」，在你后台是一整串动作。
QPS 数动作，TPS 数生意。同一个系统，QPS 通常是 TPS 的几倍到几十倍。所以「我们扛得住 10 万 QPS」听着唬人，业务方真正关心的却是「一秒能成交多少单」。
反过来也有陷阱：只报 TPS，会掩盖后端被打爆的真实压力。两个都得报。
串起来
并发数 ＝ QPS × RT
150 个在途 ＝ 500 次/秒 × 0.3 秒
QPS ＝ 并发数 ÷ RT · RT ＝ 并发数 ÷ QPS
这叫利特尔法则（Little's Law），排队论里来的。性能这摊事基本全靠它串起来，它给你两个直觉：
一、RT 一变慢，并发数立刻翻倍。流量一点没涨，RT 从 300ms 变 600ms，在途请求就从 150 变 300。线程池设 200 的话，此刻已经开始排队了——线上第一个炸的往往不是 CPU，是线程数、连接数这些「容器」。
二、想扛多少 QPS，是能算出来的。目标 1000 QPS、RT 200ms，就得同时容得下 200 个在途请求。池子只有 50，这台机器的天花板就是 250 QPS。加机器之前，先看这个数。
平均值骗人
把 100 次请求按耗时从快到慢排成一队，站在第 99 位的那个人等了多久——这就是 P99。
P50 就是中位数，一半人比它快。图里 P50 才 50ms，可平均值是 80ms——平均值比一半以上的人都惨，因为它被最右边那两根拽上去了。
P99 是最惨的那 1%。看着只有 1%，可你 QPS 是 500，那就是每秒钟有 5 个人在骂街。而且这 1% 往往不是随机倒霉蛋，是数据量最大、订单最多的重度用户。
国内文档里的 TP99 / TP999 是同一个东西的另一种写法。对外承诺一律用 P99，永远别拿平均 RT 报性能。
压到哪算够
压测就是不停加并发，看这两根线什么时候分道扬镳。
拐点之前：加并发，QPS 跟着涨，RT 几乎不动。这段是健康区。
拐点之后：QPS 涨不动了，RT 开始飙。再加，QPS 反而往下掉——排队、超时、重试，重试又制造新流量，这就是雪崩。
所以「这台机器扛多少」不是压到崩为止的那个数，是拐点那个数。日常水位建议压在拐点的 40~60%，剩下的留给突发和故障时的流量转移。
一起出现的词
Throughput
吞吐量
单位时间干完的总量，是个大类。QPS 和 TPS 都是吞吐量的一种，网络那边的吞吐量则按 Mbps 算。
Latency
延迟
严格说 RT ＝ 网络来回 + 服务端处理。服务端日志里的 20ms，到用户那边可能是 200ms。别把两个数混着用。
Error Rate
错误率
失败请求占比。脱离错误率的 QPS 全是耍流氓——秒回 5 万个 500 错误，QPS 也很好看。它必须和 QPS 挨着写。
Virtual User / Think Time
VU 与思考时间
VU 是压测工具模拟的「人」。VU 数 ≠ 并发数，中间隔着思考时间（真人两次点击之间的发呆）。不设思考时间，压出来的 QPS 虚高好几倍。
SLI / SLO / SLA
三层承诺
SLI 是你测的指标（P99 延迟）；SLO 是内部目标（P99 < 300ms）；SLA 是对外合同，违约赔钱。别把 SLO 当 SLA 报出去。
Peak vs Average QPS
峰值与日均
按二八法则估：80% 流量集中在 20% 时段，峰值 QPS ≈ 日均 × 4~6。做容量永远按峰值算，按日均算的都在半夜被叫醒过。
Connections
连接数 ≠ 并发数
长连接闲着也占着连接。10 万连接可能只有 300 个在真干活。连接数看的是资源占用，并发数看的是在途工作量。
IOPS / Bandwidth
IOPS 与带宽
磁盘和网络那一侧的「QPS」。QPS 上不去，瓶颈经常不在 CPU，而是磁盘 IOPS 打满、或者出口带宽跑满了。
Warm-up / Cold Start
预热与冷启动
刚起的进程 JIT 没编译、缓存空、连接池空，头几分钟慢得离谱。压测必须先预热 3~5 分钟再取数，否则测的是冷启动。
Long Tail / Jitter
长尾与抖动
少数请求特别慢，或者 RT 忽高忽低。常见元凶就三个：GC 停顿、慢查询、失败重试。P99 难看基本都是长尾在作祟。
Apdex
用户满意度指数
把 RT 折成 0~1 的一个分。设阈值 T：快于 T 算满意，T~4T 算能忍，更慢算不满。给不看技术的人汇报时好用。
Load / Stress / Soak Test
四种压法
基准：单接口摸底。负载：压到目标 QPS 看指标。压力：一直加到崩，找拐点。稳定性：常规流量跑 12 小时，抓内存泄漏。
举例
场景 A · 上线前估机器
「日活 100 万，人均 20 次请求，一天 2000 万次；
÷ 86400 秒 ≈ 日均 230 QPS；
按峰值 5 倍算，要扛 1150 QPS。
单机压测拐点在 400 QPS，那就 3 台起步，留冗余上 4 台。」
从日活到机器数，中间只用了「日均 QPS → 峰值 QPS → 单机拐点」三步。拍脑袋说「上 10 台吧」的人，缺的就是这三步。
场景 B · 定压测目标
「目标：1200 QPS 下，P99 < 300ms，
错误率 < 0.1%，持续 30 分钟不衰减。
先预热 3 分钟再取数，思考时间按 3 秒设。」
一个合格的压测目标必须同时有吞吐、延迟、错误率、时长四项。只写「压到 1200 QPS」，压出来一堆超时也算达标。
场景 C · 线上排障
「QPS 没变，还是 500；
RT 从 80ms 涨到 900ms；
并发数从 40 冲到 450。
并发 ＝ QPS × RT，QPS 没动 → 不是流量打上来了，
是下游变慢把线程池占满了。去查下游。」
这就是利特尔法则最实用的地方：三个数里只要有两个不动，第三个的变化就直接指向病因。QPS 平、RT 涨 ＝ 下游或自身变慢；QPS 涨、RT 平 ＝ 真流量来了，扩容就行。
别踩
所以：一律报 P99。平均值天生被长尾拽高，又天生掩盖长尾，两头不讨好。
所以：QPS、P99、错误率三个数永远一起出现。缺一个，这份报告就可以不看。
所以：标清环境——机器配置、数据量、缓存是冷是热、有没有走真实网络。空库压出来的 QPS 能比生产高一个数量级。
所以：并发数只算「此刻正在处理中」的请求。10 万人在线，同时在途的可能只有几百个——中间差的就是思考时间。
QPS 是面子，
P99 才是里子。