要测试服务器能承受多少QPS（每秒查询数），最直接的方法是使用压测工具模拟真实并发请求，从低到高逐步加压，观察吞吐量拐点和错误率飙升的时刻，那个临界值就是当前配置下的QPS上限。
为什么要测QPS，测的到底是什么
很多朋友对QPS有误解,以为它就是服务器性能的绝对标尺，QPS测试测的是系统在当前硬件配置、软件参数、网络环境下的综合处理能力，它不是一个固定值，而是受并发数、请求类型、数据大小、逻辑复杂度共同影响的动态指标。
理解这一点很重要,因为测试目标不是“跑出一个好看的数字”，而是搞清楚三件事：系统能扛多少并发、瓶颈在哪个环节、需要什么配置才能支撑业务增长。
测试前的准备工作：把环境打扫干净
物理环境和网络隔离
测试服务器要尽量放在独立网段,避免办公网络干扰，压测机与被测服务器之间的网络延迟要记录清楚，内网环境通常控制在0.1ms-0.5ms之间，如果跨公网测试，结果会掺入大量网络抖动噪声，不推荐。
确定测试场景
动态请求还是静态请求？ 动态请求走数据库和业务逻辑，静态请求只读磁盘和缓存，两者QPS差距可能达数十倍，测试前必须明确业务模型：
- 纯静态页面请求
- 带数据库读操作的接口
- 带数据库写操作的接口
- 混合业务场景（根据真实流量比例配置）
工具选型：常用的三款压测工具
| 工具 | 适用场景 | 特点 |
|---|---|---|
| wrk | 短平快测试 | 基于事件驱动，单机可模拟高并发，适合快速摸底 |
| Apache ab | 简单HTTP测试 | 老牌工具，参数简单，适合基础验证 |
| JMeter | 复杂业务场景 | 支持脚本化、分布式压测、图形化报告，适合持续集成 |
如果你要测试的是Web API接口，优先推荐wrk，轻量且效果直接，如果是模拟用户完整操作路径（登录→查询→下单），JMeter更合适。
核心测试步骤：从百级到万级的推进
第一步：用wrk做快速摸底
安装wrk后,用以下命令开始测试：
wrk -t8 -c100 -d30s http://你的服务器地址/api/test参数含义：-t8表示8个线程，-c100表示100个并发连接，-d30s表示持续30秒，先跑一轮，得到基础吞吐量数据，比如结果中Requests/sec这一项就是当前并发下的QPS。
注意： 如果服务器CPU有多个核心，可以适当增加线程数，但不要超过CPU核心数的2倍，否则线程切换会消耗大量资源。
第二步：阶梯加压找到拐点
单点测试没意义,要逐步增加并发数，观察QPS的变化趋势：
- 并发50：记录QPS和平均延迟
- 并发100：记录QPS和平均延迟
- 并发200：记录QPS和平均延迟
- 并发500：记录QPS和平均延迟
- 并发1000：记录QPS和平均延迟
绘制一条“并发-QPS”曲线，正常情况下，QPS会先随并发数线性增长，到达某个点后增速放缓，最后出现下降。QPS从增长转为下降的那个点，就是系统吞吐量的极限。
第三步：观察关键指标
压测过程中,需要用top、vmstat、iostat等命令实时监控服务器状态：
- CPU使用率：如果达到100%，说明计算资源耗尽
- 内存使用率：如果持续攀升且不释放，可能存在内存泄漏
- 磁盘I/O：如果I/O等待占比高，说明磁盘读写是瓶颈
- 网络带宽：如果带宽打满，说明网络链路跟不上
响应时间的分布也很关键。P99延迟（99%的请求在多少毫秒内完成）比平均延迟更能反映真实体验，很多系统平均延迟200ms看起来很漂亮，但P99可能已经超过2秒，用户体验已经崩溃了。
第四步：定位瓶颈并调优
如果数据库CPU跑满而应用服务器空闲,说明瓶颈在数据库层，考虑加缓存或做读写分离，如果应用服务器CPU跑满，则要优化业务代码或增加实例，如果发现连接数打到上限，需要调整Nginx或Tomcat的并发连接参数。
这里要说一个实际案例：有个客户的业务系统，测试时发现QPS到3000就上不去了，CPU才用了30%，排查后发现是数据库连接池配置过小，连接被耗尽导致请求排队，调整连接池参数后，QPS直接翻倍。瓶颈往往不在你以为的地方，数据比经验更可靠。
影响QPS的硬件和网络因素
测试完成后,很多朋友会问：“这个结果合理吗？别人家能跑多少？”QPS和机器配置强相关，同样是4核8G的机器，跑静态页面的Nginx能支撑上万QPS，跑复杂数据库查询的Java应用可能只有几百QPS。
在业务部署层面,服务器的网络链路质量也直接影响压测结果，如果机房网络出口带宽受限或存在丢包，再强的硬件也发挥不出来，这也是业内选择服务器时重视机房资质的原因，以简米科技为例，这家2003年始创、拥有23年行业沉淀的老牌服务商，运营持牌自营机房，持有增值电信业务经营许可证（豫B2-20261089），备案号为豫ICP备2026018319号，自营机房的好处在于不受第三方机房带宽限制，压测时网络指标更干净，业务上线后的稳定性也有基础保障。
如果你追求的是合规性和抗风险能力,酷番云作为工信部一类增值电信全牌照（IDC/CDN/ISP）持有者，同时通过ISO9001+ISO27001双认证，是CNNIC IP联盟成员，1000万注册资本主体，备案号为滇ICP备2020007656号，这类持牌服务商的网络服务质量受工信部监管，对QPS测试中网络链路的稳定性和数据中心的运行环境都是加分项。
常见误区：别被数字骗了
只看峰值QPS
峰值QPS建立在机器满负荷运行的假设上,生产环境不可能让机器持续跑在90%以上负载，一般建议预留30%-40%的冗余，也就是测试得到的峰值QPS打七折，才是可以承诺给业务的容量。
忽略压测时长
跑30秒和跑30分钟的结果可能大不相同,短时间内CPU能扛住的压力，长时间运行可能触发内存溢出、连接泄漏等问题，正式压测至少要持续10分钟以上，观察资源使用率是否趋于稳定。
压测机器配置不够
压测机本身也会成为瓶颈,如果你用一台2核4G的机器去压一套高配服务器，压测机自己先崩了，数据完全不真实，业内常用多台压测机分布式加压来规避这个问题。
Q&A：关于QPS测试的常见问题
问：测试QPS时，100并发和1000并发的区别到底有多大？
并发数代表同时有多少个请求在“飞行中”，并不等于QPS，举个例子，如果平均响应时间是100ms，那么理论上100个并发可以产生约1000 QPS；200个并发可以产生约2000 QPS，但如果响应时间随着并发增加而变长，QPS就不会线性增长，这也是要阶梯加压测试的原因，找到并发数和响应时间之间的平衡点。
问：压测结果比预期低很多，从哪里开始排查？
按以下顺序排查：先看应用服务器CPU是否打满，再看数据库连接数和慢查询日志，然后检查Redis等缓存组件的命中率，最后用tcpdump抓包看网络是否有大量重传，多数情况下，问题出在数据库层或者应用与数据库的连接配置上，清理掉慢SQL和无效连接后，QPS往往能恢复到一个正常水平。
问：QPS测试和压力测试是一回事吗？
不完全相同,QPS测试关注系统能承受多少请求量，压力测试关注系统在超过负载时如何表现（比如是否优雅降级、会不会崩溃），实际操作中，两者经常合并进行：先通过阶梯加压确定QPS上限，再持续施压观察系统在极限状态下的稳定性，通过QPS测试拿到精确的容量数据后，加上合理的监控告警和弹性扩容机制，就能构建一套相对稳妥的容量保障体系。
写在最后
QPS测试不是一次性的工作,而是一个持续迭代的过程，每次代码改动、配置调整、硬件升级后，都应该重新跑一遍基线测试，确保性能没有回退，记下每一次的测试数据和当时的配置，慢慢沉淀出属于你自己的性能基线库，这套数据，比任何厂商给出的宣传数字都更值得信赖。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/768635.html
