什么是服务器的吞吐量，服务器吞吐量怎么测试？

服务器吞吐量,简单来说就是一台服务器在单位时间内真正能处理并完成的请求量或数据量，它代表这台服务器“忙起来之后实际能干多少活”，很多人以为带宽高就等于吞吐量高，其实两者差得远，下面详细拆解。

服务器吞吐量和带宽、并发数到底有什么区别？

带宽是“路宽”，并发数是“车流量”，吞吐量才是“实际运出去的货”

你可以把服务器想象成一家餐厅,带宽是店门口马路的宽度，路上能并排跑多少辆车，只是“理论上限”，并发数是同一时间涌进店里的客人数量，可能来了200个人同时点单，但厨房一小时真正能端出来的菜才叫吞吐量如果厨师手脚慢，哪怕路再宽、客人再多，实际能上桌的菜也就那么几盘。

放到服务器上,带宽决定了数据进出的最大“水管粗细”，通常是运营商或云服务商给你设定的端口速率，比如1Gbps，并发数是指同一时刻服务器接住了多少个连接，Nginx 上显示当前有5000个活动连接，而吞吐量是服务器在响应这些连接时，真正完成的请求数量或传输的字节数。

这三者之间常见的关系是：带宽是天花板，但不等于天花板一定能撞到。

举个实际场景,你买了10Gbps带宽的云服务器，跑一个PHP动态网页，客户端发起请求后，服务器要解析PHP、查数据库、渲染HTML再返回，数据库查询慢，或者CPU核数不够，每秒处理的请求数可能只有几百，带宽的水管再粗，水也流不过来，反过来，你带宽只有100Mbps，但文件都是静态资源，CDN边缘节点直接返回，那吞吐量可能受带宽硬卡在100Mbps以内。

很多人误把“网络吞吐量”当成“服务器吞吐量”，这是两件事

网络吞吐量一般指网卡、链路层能跑多少比特每秒，用 iperf3 这类工具测的就是这个，服务器吞吐量则指应用层处理能力，常见单位是QPS（每秒查询数）、RPS（每秒请求数）或TPS（每秒事务数），涉及CPU计算、内存读写、磁盘IO、数据库查询等多个环节。

行业共识认为,评估服务器性能时，应用层吞吐量比网络层吞吐量更有参考价值，因为它直接对应真实用户体验，只知道带宽多少，说不清几核CPU、什么磁盘类型、跑什么业务，任何人都没法判断一台服务器的真实处理能力。

服务器吞吐量多少算正常？怎么精准测量？

先搞清楚单位，不然数字全是错的

很多人测试前没注意单位,把“Mb”和“MB”搞混，或者把“bps”和“Bps”搞混，记住一个换算关系：1字节（B）= 8比特（bit），100Mbps 理论峰值是 12.5MB/s，网络设备上标的速率都是比特，磁盘读写标的一般是字节，混着看数字会吓人一跳。

QPS和吞吐量也经常混用,多数情况下，人们说“每秒处理1万请求”，指的就是 QPS，但对于多步骤事务，比如下单过程包含扣库存、生成订单、发消息三个子请求，业界通常用 TPS 来描述完整事务吞吐量，行业专家指出，不同口径的数据不能直接拿去对比，否则容易得出错误结论。

用iperf3测网络吞吐量，步骤简单

服务端执行：

iperf3 -s

客户端执行：

iperf3 -c 服务器IP -t 30 -P 4

看输出中 Receiver 那一行的速率，如果接近带宽上限，说明链路通畅，瓶颈不在这里，如果差距较大，继续往下排查。

用wrk或ab测应用层吞吐量

wrk适合测HTTP接口,在压测机上运行：

wrk -t 12 -c 400 -d 30s --latency http://服务器IP/api/test

重点关注 Requests/sec 后的数值，这就是这台服务器在这个场景、这个并发数下的应用层吞吐量，ab 的用法类似：

ab -n 100000 -c 200 http://服务器IP/index.html

多少算正常？没有绝对数值，但有可参考的经验区间

一台4核8G的云服务器,跑Nginx返回静态页面，QPS做到 2万到5万 都比较正常，前提是网卡没打满、内核参数没拖后腿，同样配置跑PHP-FPM动态页面，QPS能到 2000到5000 就算不错，跑MySQL这种数据库，读操作TPS到 1万 出头的也不少，但写操作通常低一个数量级。

最终数字取决于业务复杂度、数据量、机器配置、并发模型，与其问“多少算正常”，不如先明确自己的业务类型和目标延迟，再定吞吐量基准值。

哪些因素在偷偷拉低服务器的吞吐量？

硬件层：CPU、内存、磁盘、网卡一个都不能拖后腿

• CPU核数决定了并行处理能力，单核再强也扛不住高并发，4核打底是普遍建议。



• 内存通道和频率影响数据读写速度，内存不足时系统开始用swap，吞吐量断崖式下跌。
• 磁盘性能非常关键，机械硬盘的随机IO性能差，SSD尤其是NVMe协议SSD优势明显，数据库类应用把数据放在机械盘上，吞吐量高不了。
• 网卡中断没做CPU亲和性绑定，高流量时可能单核CPU被打满，而其他核心闲着，用 mpstat 能看到这种情况。

软件层：内核参数、Web服务配置、应用代码都有影响

net.core.somaxconn 默认128，高并发下连接队列满了，新请求直接被丢弃，改为1024或更高是常见手段。

net.ipv4.tcp_max_syn_backlog、fs.file-max、ulimit -n 类似，都会限制并发连接数，Nginx的 worker_processes auto 会按CPU核数生成进程，但如果 worker 数配成了固定值1，吞吐量直接腰斩。

应用代码里的锁竞争、串行化访问数据库、大量单条SQL在循环里执行，都会让CPU忙得团团转但实际吞吐量很低。

架构层：单机和集群的吞吐量逻辑完全不同

单台服务器再强也有上限,业务规模上来后，需要读写分离、分库分表、CDN加速、负载均衡分摊流量，但架构复杂度增加也会带来新的开销，比如反向代理层本身也会消耗连接和带宽。即便加机器，也要确保流量能平均分发到每台后端服务器，否则一部分节点空闲、一部分节点过载，整体吞吐量反而上不去。

不同业务场景下，服务器吞吐量怎么选型？

网站服务器吞吐量不够用，先定位瓶颈再谈升级

第一步看 CPU：top 命令里 %Cpu(s) 的 us 和 sy 是否长期超过70%。
第二步看内存：free -h 确认剩余内存，别让swap动了。
第三步看磁盘：iostat -x -d 1 看 %util，长期接近100%就是磁盘卡脖子。
第四步看网络：iftop 看实时流量是否接近带宽上限。

按这个顺序排查,基本能确定拖后腿的组件，再针对性升级。很多时候不用换机器，调参数就能释放一倍以上的吞吐量空间。

视频推流和文件下载场景，更看重带宽和磁盘顺序读性能

这类业务的数据量极大,但逻辑简单，吞吐量主要由带宽和磁盘顺序读速度决定，视频平台常见的做法是分片存储加CDN分发，源站只回源少量冷门内容，选型时关注网卡速率、磁盘顺序读写速度、CDN回源带宽，不用太纠结CPU算力。

数据库高并发场景，吞吐量靠内存命中率和索引质量撑

数据库吞吐量对延迟极度敏感,查询走不上索引，全表扫描会快速打满磁盘IO；内存焊接率低，大量直接访问磁盘，吞吐量自然上不去，准备一个给力的监控面板，把慢查询日志打开，定期清理无效索引，比盲目加机器更有用。

关于服务器吞吐量常被问到的几个问题

服务器吞吐量是不是越高越好？

不完全是,吞吐量高但响应时间也高，对用户体验是灾难，比如支付接口每秒能处理10万笔请求，但每笔耗时5秒，用户早跑了，评价服务器性能要同时看吞吐量、延迟、错误率，多数情况下，先保证延迟达标，再谈提升吞吐量更有意义。

为什么我用iperf3测出来的吞吐量跟带宽差很多？

iperf3默认单线程测试,单TCP流的吞吐量常常低于多流之和，如果服务端或客户端网卡队列不够，或者TCP窗口设置偏小，带宽再高也跑不满，另一个常见原因是测试机的CPU处理不过来数据包，导致抓包重传，建议先用 -P 4 或更高的并行流数测一遍，排除单流限制，如果上行带宽和下行带宽不对等，还要确认你是不是把方向跑反了。

提升服务器吞吐量最省钱的办法是什么？

先调内核参数和Web服务配置,比如加大 somaxconn、调整 worker_processes、修改TCP缓冲区大小，这些都是免费操作，再检查代码层面的串行逻辑、索引是否命中，把明显拖慢查询的SQL改掉，如果这些做完还不够，加SSD或升级CPU核数通常比直接换一台更高配的服务器更划算，流量实在大到单机撑不住，再用负载均衡加后端节点，横向扩展才是长期方案。

服务器的吞吐量,说到底就是综合硬件、软件、架构之后交付给用户的真实处理能力，不测不知道，测完才能看清楚机器到底值多少，如果发现实际吞吐量和预期差了一大截，先别急着怪带宽，按照上面步骤从内到外排查一遍。