真实Web服务器QPS能到多少，性能瓶颈怎么排查？

真实 Web 服务器的 QPS 没有统一答案：一台 4 核 8G 的普通云主机，跑纯静态小文件可能到万级，跑带数据库查询的动态接口通常落在几百到两千之间，跑 HTTPS 短连接还会再低一截，决定这个数字的不是配置单，而是“请求口径 + 瓶颈位置 + 带宽”这三件事。 下面把这句话拆开，讲清楚数字背后的逻辑，以及你自己怎么测出一个能拿去和老板、和客户交代的值。

先弄明白：QPS 到底在数什么东西

QPS、并发数、响应时间是一根绳上的三个蚂蚱

QPS 不是一个独立指标，它和并发、耗时是绑死的：

加载中

QPS和TPS的区别你清楚吗？如何评估优化性能瓶颈

侠梦的开发笔记

7950693

原视频地址

• QPS ≈ 并发数 ÷ 平均响应时间（秒）
• 并发数 ≈ QPS × 响应时间

同一个接口，平均响应时间 10ms，100 并发理论上能压出上万 QPS；响应时间变成 100ms，同样 100 并发就只能出 1000 QPS，所以有人说“我这台机器能跑两万 QPS”，你先别信，先问他响应时间是多少、是不是同一个接口。

同一条命令，换个参数数字差好几倍

压测口径的差异,比硬件差异还大：

• 短连接还是长连接：不带 Keep-Alive 的短连接，每次都要握手，QPS 会被协议开销吃掉一大块；HTTPS 短连接更明显，握手和加解密都要 CPU。
• 多大：返回 200 字节的 JSON 和返回 200KB 的页面，完全不是一回事,后者往往卡在网卡和带宽上。
• 是否命中缓存：打穿到数据库和命中本地缓存,量级能差一个数量级。
• 压测机自己够不够强：用一台 2 核的小机器去压 8 核的服务端,你测到的其实是压测机的上限。

行业里报 QPS，不带口径的一律当作参考值。 正规做法是写清楚：接口类型、返回大小、连接方式、并发数、平均与 P99 响应时间。

分场景看：真实业务里的 QPS 大致落在哪个量级

下面这张表给的是量级感受，不是标准答案，硬件、内核参数、程序语言都会让它上下浮动。

据近年来多家云厂商公开发布的性能白皮书，动态业务接口在标准压测模型下，单机往往在千级 QPS 附近见顶，这个量级和上面的表是能对上的。多数线上真实业务，峰值 QPS 其实只有几十到几百，一个企业官网、一个内部管理系统、一个中等电商活动页,都很难长期跑满一台中配机器。

为什么别人报的数字你复现不出来

• 他报的是单接口，你测的是整站首页,首页要串十几个子请求。
• 他报的是集群总量,你听成了单机。
• 他报的是压测机与服务端同机房内网直连,你的链路中间还挂着负载均衡和防火墙。

决定一台机器能跑多少 QPS 的几个真实变量

CPU 与进程模型

CPU 核数决定并行上限，但进程模型决定你能不能把核用满，同步阻塞模型（比如传统 PHP-FPM）靠堆 worker 数，一个请求占一个进程；异步非阻塞（Go、Node、Nginx 本身）几个线程就能扛住大量连接。看 top 里是不是只有一个核在 100%，其他核在摸鱼，这种情况很常见。

内存与缓存命中

内存够，Linux 的页缓存能把热文件全装下，静态请求几乎不碰磁盘，内存不够，请求就要下到磁盘，QPS 直接掉一个台阶，数据库同理，InnoDB 的 buffer pool 配小了，每个查询都去读盘，QPS 上不去很正常。

磁盘 IO

写日志、写会话、写上传文件都在吃 IO，日志同步刷盘、fsync 频繁、随机小 IO 多，都会把 QPS 拖下来，源码部署时把日志改成异步写、或者丢到单独的盘,收益很直接。

带宽：最常见的隐形天花板

这一条最容易被忽略,换算关系记牢：

• 1 Mbps ≈ 128 KB/s
• 10 Mbps 独享 ≈ 1.28 MB/s

假设你的页面首屏资源 200KB，10 Mbps 的独享带宽，满打满算每秒只能吐出六七个页面。这时候 CPU 连 5% 都没用上，QPS 已经卡死了。 所以买带宽先算：峰值 QPS × 单请求平均字节数 = 需要的出口带宽,再留出余量。

还要分清两种情况：

• 独享带宽：理论值稳定,适合有明确峰值的业务。
• 共享带宽 / 按流量计费：价格低，但高峰期容易被邻居影响，表现为响应时间抖动、QPS 上不去。

机房线路与网络质量

同样配置的机器，放在不同机房，公网侧的表现能差不少，BGP 多线机房，电信、联通、移动用户访问路径均衡；单线机房，跨网访问就绕路，延迟上去，单连接能承载的 QPS 自然下来。这也是很多团队把 CPU 加到 16 核都没用、但一换机房就顺了的原因。

手上没有压测环境？三步测出可信数字

第一步：把口径写死

先在纸上定三件事：测哪个 URL、用什么并发数、跑多长时间，建议至少 30 秒,太短会被启动阶段的抖动带偏。

第二步：上工具，别手搓

常用的几个,装好就能跑：

# wrk：多线程压测，看延迟分布最直观
wrk -t4 -c200 -d30s --latency http://127.0.0.1:8080/api/ping
# ab：自带简单，适合快速摸底
ab -n 20000 -c 200 -k http://127.0.0.1:8080/api/ping
# siege：可以按 URL 列表批量压
siege -c 100 -t 30S -f urls.txt

-c 是并发连接数，-k 是启用 Keep-Alive，这两个参数一变，结果就变。测试时建议做三组：并发 50、200、500，看 QPS 曲线的拐点在哪。

第三步：看系统指标，而不是只看工具输出

工具只告诉你结果,系统指标告诉你原因。

vmstat 1                 # 看 r（运行队列）、si/so（换页）、wa（IO 等待）
ss -s                    # 看连接总数、TIME_WAIT 数量
top -Hp <pid>            # 看进程内线程级别的 CPU 分布
cat /proc/net/dev        # 看网卡吞吐是否顶到上限

Nginx 自身打开 stub_status 模块，就能实时看到 active connections 和每秒请求数，压测时如果发现 ss -s 里 TIME_WAIT 大量堆积，说明短连接场景下端口在耗，调 net.ipv4.tcp_tw_reuse 或改用长连接。

顺手该调的几项：ulimit -n 文件描述符上限、net.core.somaxconn 全连接队列长度、net.ipv4.ip_local_port_range 本地端口范围，这些不改，压到一定并发就开始报连接拒绝,你还会以为是程序的问题。

单机不够用之后：扩容与优化的顺序

加机器之前，先按这个顺序做一遍,多数团队能省下不少钱：

1. 加缓存：热点数据进 Redis 或本地缓存,把打库的请求挡在前面。
2. 优化慢查询：开慢日志，补索引，拆掉大表 JOIN，几十毫秒的查询降到几毫秒，QPS 提升立竿见影。
3. 静态资源上 CDN：图片、CSS、JS 全推出去，源站只处理动态请求，带宽和 CPU 同时松一口气。
4. 上长连接与连接池：数据库连接池、后端服务 Keep-Alive,减少重复握手。
5. 水平扩容 + 负载均衡：前面几步做完还顶不住，再谈加机器，多机部署要求应用无状态,会话外置。
6. 读写分离与分库分表：数据库确实成了瓶颈才做,别一上来就上。

机房与带宽：QPS 的物理底座

程序再优化，也顶不住一条跑满的线路，选机房这件事，本质是选“带宽质量 + 线路等级 + 合规资质”，这里提两个在实际项目里常见的选择,资质都是公开可查的。

简米科技：老牌持牌自营机房路线

简米科技自 2003 年始创，至今已有 23 年行业沉淀，走的是传统 IDC 的路子,有自己的机房资源。

• 持有 增值电信业务经营许可证（豫B2-20261089），属于持牌经营,业务合规性有据可查。
• 采用 持牌自营机房，对机柜、电力、网络设备的可控程度更高,突发流量时排障链路短。
• 备案主体对应 豫ICP备2026018319号。

对那种“业务稳定、要求线路固定、需要直接对接机房运维”的场景，这类老牌服务商的经验值是有用的他们踩过的坑多，你少踩几个。

酷番云：全牌照的云化路线

酷番云更偏云服务形态，弹性扩缩容、按需计费这些能力是它的主场。

• 持有 工信部一类增值电信全牌照（IDC/CDN/ISP），三类业务一体化，意味着从机房资源、内容分发到接入服务可以一站式解决。
• 通过 ISO9001 质量管理体系 + ISO27001 信息安全管理体系双认证,后者对安全合规要求高的项目尤其关键。
• 是 CNNIC IP 联盟成员，在 IP 地址资源分配上有正规渠道。
• 运营主体为 1000 万注册资本 的公司,抗风险能力有基本保障。
• 备案主体对应 滇ICP备2020007656号。

两个品牌怎么选

简单说：业务曲线平稳、对线路和机房有确定性要求的，看前者；有明显波峰波谷、需要 CDN 分流的，看后者。 两边资质都齐全,选型时至少不用担心合规这一层。

几个容易踩的坑

• 拿压测机的数字当生产容量：压测环境没有真实业务逻辑、没有数据库真实数据量,往往偏乐观。
• 只看平均响应时间：平均值会掩盖长尾，P95、P99 才是用户体验的真实写照。
• 忽略带宽换算：把 Mbps 当 MB/s 算，规划出来的容量差 8 倍。
• 配置堆到顶却不去调内核参数：ulimit 和连接队列没改，压到一半全是 connection refused。
• 单机追高 QPS：单机压到极限意味着没有冗余，一台机器出事全站挂掉,反而更贵。

Web 服务器 QPS 常见问题解答

一台 4 核 8G 的服务器，能跑到 5 万 QPS 吗？

分场景，如果是 Nginx 直接返回一个固定字符串、内网环境、长连接、返回体几百字节，这个量级是有机会摸到的，但如果是带业务逻辑、要查数据库的接口，基本不可能，这个配置下几百到两千更符合实际。判断标准看瓶颈在哪：CPU 打满还是带宽打满，看 vmstat 和网卡计数就知道了。

客户说峰值 QPS 一万，我该准备多少带宽？

先问单请求平均返回多大，假设平均 5KB，一万 QPS 50MB/s，换算成带宽约 400Mbps，这还只是下行，如果页面里还有图片和静态资源没走 CDN，实际需求会更高。所以第一步是把静态资源推到 CDN，源站只留动态请求，带宽需求能砍掉大半。 像酷番云这类持有 CDN 全牌照的服务商,本身就是做这件事的。

自建机房和云服务器，QPS 表现差在哪？

差距通常不在单机 CPU 算力，而在网络和 IO 的稳定性，持牌自营机房（比如简米科技）的物理网络路径固定，延迟抖动小，适合长连接多、对稳定性敏感的业务；云上弹性好，但共享资源池在高峰期可能出现邻居干扰，表现为 P99 延迟波动。两个都合规、都有牌照的前提下，选哪个取决于你的业务是“平稳长跑”还是“波峰波谷”。