Web服务器QPS和并发连接数有什么区别？性能指标详解

做性能测试时，两句话最容易吵起来："我这台机器能扛 5000 并发"和"我这台机器 QPS 只有 800"。听起来都在说性能，其实是两个完全不同的东西。搞不清 QPS 和并发连接数的区别，压测报告就会写成糊涂账：明明并发拉到了几千，QPS 却上不去，到底是机器不行还是参数不对？

这篇文章把这两个指标讲清楚：QPS/TPS 是什么、并发连接数是什么、它们差在哪、用 Little's Law 怎么换算、压测中怎么分别测量、以及几个最常见的误解。理解之后，你就能一眼看穿别人性能报告里"并发"到底指什么，也能自己估算服务器容量。

一、QPS / TPS：速率指标

QPS（Queries Per Second） 指每秒处理的请求数，是"速率"。它回答的问题是：单位时间内，服务器处理完多少个请求。单位是"次/秒"。

TPS（Transactions Per Second） 指每秒完成的事务数。事务可以理解为一次完整的业务操作，可能包含多个请求。比如一次下单，内部可能查库存、扣库存、生成订单、发消息，是若干请求组成的一个事务。所以 TPS 的口径通常比 QPS 粗，数值一般也小于等于 QPS。

两者都是"速率"，衡量的是吞吐能力。它们的特点是：只要业务稳定，这个数字在一段时间内是相对持续的。

二、并发连接数：瞬时并存数

并发连接数指同一时刻处于"打开并处理中"状态的连接或请求数量，是"瞬时值"。

要特别区分两个容易混的概念：

• 并发连接数（TCP 层面）：服务器上同时保持着多少条 TCP 连接。用 ss -s 或 netstat 能看当前状态。很多连接可能是 keep-alive 空闲挂着的，不消耗多少 CPU。
• 活跃并发（请求处理层面）：同一时刻正在被处理的请求数。这个才和 QPS 强相关。

"并发 5000"到底是 5000 条空闲长连接，还是 5000 个正在处理的请求，性能含义天差地别。 前者可能很轻松，后者可能直接把服务器压垮。所以谈并发，一定要说清楚是哪一种。

三、两者到底差在哪

一句话概括：QPS 是"每秒做了多少"，并发是"同一时刻有多少在做"。 一个是流量（速率），一个是存量（水位）。

关键点：两者由"响应时间"连接起来，不是一回事，也不能互相替代。 高并发不等于高 QPS，低并发也可能有高 QPS。

四、用 Little's Law 建立换算

用一个经典的排队论关系，能把这几个量串起来：

并发数（L）≈ QPS（λ）× 平均响应时间（W）

其中响应时间单位用秒。这个式子非常实用，能解释很多现象：

• 例子 1：服务器 QPS 1000，平均响应时间 50 毫秒（0.05 秒），那么需要的并发约为 1000 × 0.05 = 50 个。也就是说，这台机器只要同时有 50 个请求在飞，就能支撑 1000 QPS。
• 例子 2：如果响应时间涨到 200 毫秒，同样想撑 1000 QPS，需要并发 1000 × 0.2 = 200 个。响应变慢，同样的 QPS 需要更多并发。
• 例子 3：反过来，客户端只给 100 个并发，但响应时间只有 20 毫秒，理论 QPS 上限约 100 ÷ 0.02 = 5000。并发少也能有高 QPS，前提是处理够快。

这个式子的实战价值：压测时想达到某个 QPS，可以用它反推需要设置多少并发。 想测 5000 QPS、预估响应 20ms，就把并发设到约 100 起步再往上加。

五、压测中怎么分别测量

用 wrk 举例，一条命令同时能看到两个维度：

# -t 线程数，-c 并发连接数，-d 持续时长，--latency 输出延迟分布
wrk -t4 -c100 -d30s --latency http://127.0.0.1:8080/

输出里：

Running 30s test @ http://127.0.0.1:8080/
  4 threads and 100 connections        # 这里的 100 就是并发连接数 -c
  Thread Stats   Avg      Stdev     Max
    Latency    12.34ms   ...        # 平均响应时间，换算 Little's Law 用它
    Req/Sec   850.00     ...        # 每线程每秒请求数
  Requests/sec:   3200.00              # 这就是 QPS

• 并发数：-c 参数就是你设定的并发连接数。
• QPS：看 Requests/sec。
• 平均延迟：看 Latency 的 Avg。
• 验证 Little's Law：Requests/sec × Latency(秒) ≈ 并发。3200 × 0.01234 ≈ 39.5，接近但略小于 100，差值来自连接建立、等待等开销，属正常。

用 ab 也能看：

# -c 并发，-n 总请求数
ab -c 100 -n 100000 http://127.0.0.1:8080/
# 关注 Requests per second（QPS）和 Time per request（响应时间）

同时，服务端看连接占用：

# 看当前连接状态汇总（推荐）
ss -s

# 看监听端口上的连接数与状态分布
ss -tan | awk 'NR>1{print $1}' | sort | uniq -c

把客户端的并发设置、QPS 结果和服务端的连接数、CPU/内存一起看，才能判断瓶颈到底在哪。

六、几个最常见的误解

误解一：并发数等于 QPS。 完全错。并发 1000、响应 10ms，QPS 能到十万；响应 1 秒，QPS 只有 1000。两者差了倍数量级，取决于响应时间。

误解二：并发越高 QPS 越高。 不一定。并发加到某个点后，QPS 到顶甚至下降——因为资源饱和后，请求排队、响应变慢，反而拖低吞吐。存在最优并发点，超过就劣化。

误解三：连接数高就是压力大。 长连接空闲挂着，连接数很高但压力很小。要看活跃请求数，而不是 TCP 连接总数。

误解四：TPS 和 QPS 一样。 一个事务可能包含多个请求，两者口径不同，不能混用。谈指标时先说清单位定义。

误解五：只看 QPS 不看响应时间。 高 QPS 但响应时间飙到秒级，业务体验一样崩。要 QPS、响应时间（尤其 P95/P99）、错误率一起看。

七、从访问日志估算 QPS

没有压测工具时，分析线上访问日志也能估算 QPS，这是运维日常常用的一招。

# 统计一天的总请求数
wc -l /var/log/nginx/access.log

# 按秒统计请求数，取最忙的那一秒（近似峰值 QPS）
awk '{print $4}' /var/log/nginx/access.log \
  | cut -d: -f1-3 | sort | uniq -c | sort -rn | head -5

# 统计每秒请求数分布（示例：统计出现的最大秒级请求数）
grep -o '\[[0-9]*/[A-Za-z]*/[0-9]*:[0-9:]*' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn | head -5

判读要点：

• 平均秒级请求数 乘上业务时长，得到日均；最忙那一秒的请求数 近似峰值 QPS。两者之差就是峰值系数。
• 看日志统计出的峰值 QPS，和监控面板、压测结果对照，三者应该大致吻合，否则说明某一处的口径有问题。
• 日志里的高峰时段要和业务的用户行为对上，避免把爬虫、扫描流量误当成真实业务峰值。

把日志统计的 QPS 和同时段的连接数（ss -s）一起看，就能估算出当时的平均响应时间（用 Little's Law 反推），从而判断系统是"忙但快"还是"忙且慢"。

常见问题

Q1：怎样判断服务器该报"并发能力"还是"QPS"？
面向接入和容量，讲 QPS/吞吐；讲连接保持、长连接、WebSocket 场景，讲并发连接数。更严谨的做法是两个都报，并注明响应时间。

Q2：并发设多少才合适？
先用 Little's Law 估：目标 QPS × 预估响应时间。然后从小到大阶梯加压，观察 QPS 和响应时间，找到 QPS 接近峰值、响应时间还没明显劣化的点。

Q3：响应时间用什么口径算？
用平均响应时间做粗略估算，但决策要看 P95/P99。平均值会被少数快请求拉低，掩盖长尾慢请求。

Q4：QPS 和带宽有关系吗？
有。每个请求平均返回多少字节 × QPS 就是所需带宽。大响应体的接口，可能先撞带宽瓶颈。

Q5：为什么压测 QPS 上不去，但 CPU 也不高？
瓶颈可能不在 CPU，而在磁盘 IO、网络、连接数上限、下游依赖、锁竞争或压测机自身。要分层排查，不能只盯 CPU。

Q6：QPS 和并发数，容量规划时该按哪个定机器数量？
按峰值 QPS 定更直接：先算出业务峰值 QPS，再除以单机压测得到的稳定 QPS，得到机器数，最后叠加冗余。并发数是"验证和调参"用的中间量，用来反推压测参数、判断响应时间是否合理，一般不直接用来定机器数量。

总结

• QPS/TPS 是"速率"，衡量每秒处理多少；并发连接数是"瞬时并存数"，衡量同时有多少在处理，两者不是一回事。
• 关键公式：并发 ≈ QPS × 平均响应时间（Little's Law），用它既能解释现象，也能反推压测参数。
• 谈并发必须说清是 TCP 空闲长连接还是活跃请求，否则没有意义。
• 压测中：-c 是并发，Requests/sec 是 QPS，Latency 是响应时间，三者对照看，并用公式互相验证。
• 别只看 QPS，要结合响应时间（P95/P99）、错误率和资源使用；并发不是越高越好，存在最优值。