吞吐测试基础：吞吐量、延迟、并发等核心概念
做吞吐测试之前，咱们先得把三个最基础的参数搞清楚。吞吐量、延迟、并发，说白了就是系统性能的三根柱子。我刚开始接手性能测试时，总把它们割裂开看，后来才发现——这三个东西拧在一起，牵一发动全身。
吞吐量（Throughput）——系统能处理多少
吞吐量，就是在单位时间内系统能完成多少业务量。比如一个订单接口，每秒能处理1000笔下单，那它的吞吐量就是1000 TPS（Transactions Per Second）。我个人习惯用“每秒事务数”或者“每秒请求数”来度量。
记得有一次压测一个消息队列系统，我们盯着QPS冲到3000时数据库连接池就报错了。我发现一个坑：吞吐量不是独立指标，它受并发线程数和延迟的直接影响。
吞吐量计算公式（简化版）
吞吐量 ≈ 并发数 / 平均延迟这个公式是理想状态，但实际项目中资源争抢会导致曲线先升后降。
| 系统类型 | 典型吞吐量范围 | 度量单位 |
|---|---|---|
| 静态页面CDN | 10万～100万 QPS | Queries Per Second |
| 业务API网关 | 1千～5万 TPS | Transactions Per Second |
| 数据库主库 | 500～5000 QPS | Queries Per Second |
延迟（Latency）——到底要等多久
延迟就是从一个请求发出到收到完整响应所花的时间。我习惯把它拆成三段看：网络传输耗时、排队等待耗时、实际处理耗时。
最有意思的是，我曾经遇到过一种情况：吞吐量明明很低，延迟却高得离谱。排查后发现是数据库连接池配置过小，大部分线程都在等连接。你想想看，这时候降延迟反而要先提并发上限。
延迟的分位值比平均值重要
我建议关注P99（99%请求的延迟上限）和P999。平均值容易被极端值掩盖，比如100个请求里99个耗时10ms，1个耗时10s，平均也有110ms，但其实大部分用户感受很好。
- 网络延迟：受物理距离、带宽、中间设备影响
- 排队延迟：线程池/连接池/队列满了，请求等待被处理
- 服务延迟：CPU计算、磁盘IO、远程调用等
并发（Concurrency）——同时来了多少人
并发指的是系统同时承载的活跃请求数量。注意，不是每秒新建连接数，而是“此刻同时进行中的请求数”。我在项目中见过最典型的问题：并发从200涨到300时系统突然雪崩。为什么会这样？因为线程池默认200，超过后就排队，排队队列一满直接拒绝，然后客户端疯狂重试，形成恶性循环。
并发 ≠ 并行
并发是逻辑上的“同时存在”，并行才是物理上的“同时执行”。单核CPU也能承载高并发，靠时间片切换。但如果你以为并发数等于线程数，那就错了——线程切换本身也有开销。
我常用的一个比喻：吞吐量是马路上的车流量（辆/分钟），延迟是每辆车从A到B的通行时间，并发就是马路上同时有多少辆车。这三者有个经典关系：当并发超过系统容量上限时，延迟会急剧上升，吞吐量反而下降——这就是“拐点”。
三者的权衡——没有免费的午餐
在真实系统中，这三个参数不可能同时达到最优。比如你想压低延迟，可以限制并发数，但吞吐量就上不去；你想冲高吞吐量，就得允许队列缓冲，延迟自然变大。我做过一个支付系统的压测，当时为了把P99延迟从200ms降到50ms，改了线程模型和IO策略，结果吞吐量从5000 TPS跌到2000 TPS。后来我们才在60ms + 4000 TPS上达成业务一致。
| 优化目标 | 对吞吐量的影响 | 对延迟的影响 | 对并发的需求 |
|---|---|---|---|
| 提升吞吐量 | —— | 通常增加 | 需适度提升 |
| 降低延迟 | 通常下降 | —— | 需控制上限 |
| 提升并发上限 | 先升后降 | 显著增加 | —— |
嗯，到这里你应该明白了：吞吐量、延迟、并发不是孤立的指标，它们是同一个系统的三个侧面。做性能测试时，拿到一个指标就要去想另外两个会怎么变。我个人经验是：先确定业务能接受的延迟上限，然后用这个上限倒推最大并发数，最后看这个并发下吞吐量是否达标。反过来推也行，关键是别只盯着一个数。