Nginx的性能测试方法，评估服务器的性能和容量

一、为啥要折腾Nginx性能测试

如果你在用Nginx做网站或API网关，肯定遇到过这样的场景：平时访问挺流畅，一到搞活动或者流量高峰期，服务器就卡成狗，甚至直接罢工。这时候你就得弄清楚，到底是Nginx本身扛不住，还是后面业务逻辑拖了后腿，又或者是硬件资源不够用。性能测试就是为了提前摸清服务器的底细，知道它能同时处理多少请求、响应时间多长、会不会因为负载过高而崩溃。这样我们就能做出容量规划，比如需要几台机器、配置怎么调才划算。说白了，就是给服务器做个“体检”，别等到出问题才后悔。

二、测Nginx性能，用啥工具好

目前社区里比较流行的压测工具有好几个，各有各的脾气。我挑几个最常见的说说，重点是让大家明白怎么选择。

2.1 ab（ApacheBench）——老牌工具，简单粗暴

ab是Apache自带的压测工具，虽然名字带Apache，但对Nginx一样管用。它用法极其简单，一条命令就能发一堆请求。缺点是只能测单次请求，不能模拟复杂场景，比如登录、Cookie、动态参数啥的。不过对于初学入门或者快速看看Nginx的静态文件服务能力，ab够用了。

2.2 wrk——现代压测小钢炮

wrk是一个轻量级的压测工具，支持多线程，还能用Lua脚本自定义请求逻辑，比如模拟用户登录、发JSON数据、读文件等。它的输出信息很全，包括请求延迟分布、吞吐量等，特别适合做带宽和连接数的测试。我平时主要用wrk，因为它速度快，结果直观。

2.3 siege——支持并发且能记录稳定性

siege也是一个老牌工具，和ab类似，但可以设置并发用户的增加和减少，模拟波浪式压力。它还会记录请求失败的数量以及平均响应时间，方便我们看服务器崩溃点。不过siege对长连接支持一般，最新版本有改进。

2.4 其他工具比如Vegeta、Hey

这些工具也能做HTTP压测，Vegeta是Go写的，Hey是Python写的，各有特色，但原理差不多。初学者建议先从ab或wrk开始，学会了再换别的。

三、测试前要准备些啥

直接拿生产环境的Nginx一顿压测可不行，那会把用户搞丢。我们得先搭一个测试环境，最好和线上配置一样，只是流量不同。下面列出几个关键步骤。

3.1 准备一个干净的测试机

压测工具运行在客户端机器上，Nginx跑在服务端机器上。两台机器最好在同一内网，避免外网延迟干扰结果。客户端机器性能要够强，不然压测工具自己先满载了，测出来的数据就失真。一般建议客户端CPU核心数是服务端的2倍以上，内存8G以上。

3.2 调整Nginx和操作系统参数

Nginx默认配置对性能有限制，得做些优化才能测出真实水平。比如：

修改worker_processes为CPU核心数，充分利用多核。

调整worker_connections到65535以上，允许更多并发连接。

开启keepalive，减少短连接开销。

修改Linux系统文件句柄限制：ulimit -n 100000。

3.3 确认被测试的接口

你要明确测什么：是静态资源（如HTML、图片），还是反向代理到后端的动态接口，或者是简单的健康检查页？不同的场景结果差异很大。最好单独测一个简单的接口，比如返回“ok”的文本，排除业务逻辑干扰。

四、动手压测，看实例

我以wrk为例，演示如何测Nginx的静态页面性能。技术栈：bash命令行（因为wrk是命令行工具）。假设Nginx已经部署在192.168.1.100，监听80端口，根目录下有一个test.html文件，内容就一个单词“hello”。下面是具体步骤。

4.1 安装wrk

# 在客户端机器上（比如Ubuntu）安装wrk

sudo apt-get update

sudo apt-get install -y build-essential libssl-dev git

git clone https://github.com/wg/wrk.git

cd wrk

make

# 编译好后，把wrk复制到/usr/local/bin方便调用

sudo cp wrk /usr/local/bin/

4.2 简单压测：单次请求，看基本能力

# 使用2个线程，10个连接，持续10秒，请求http://192.168.1.100/test.html

wrk -t2 -c10 -d10s http://192.168.1.100/test.html

解释一下参数：

-t2 表示用2个线程（线程数通常等于客户端CPU核数）

-c10 表示启动10个HTTP并发连接（模拟10个用户同时访问）

-d10s 表示持续10秒

运行后会输出类似这样的结果（示例）：

Running 10s test @ http://192.168.1.100/test.html

2 threads and 10 connections

Thread Stats Avg Stdev Max +/- Stdev

Latency 1.23ms 456.72us 5.61ms 70.23%

Req/Sec 4,321.32 237.41 5,010.00 70.23%

Latency Distribution

50% 1.08ms

75% 1.45ms

90% 1.89ms

99% 4.23ms

43128 requests in 10.00s, 7.32MB read

Requests/sec: 4312.82

Transfer/sec: 749.52KB

看结果：平均延迟1.23ms，每秒处理4312个请求。这个数值受机器性能影响，如果换成低配虚拟机可能只有几百。

4.3 增加并发量，找拐点

刚才并发只有10，现在加到100，看看Nginx能不能撑住：

wrk -t2 -c100 -d30s http://192.168.1.100/test.html

如果一切正常，每秒请求数可能会升高到几万。但继续加并发到500、1000，你会发现请求数不再线性增长，甚至出现错误连接或超时。这就是Nginx的极限。记录下这个拐点，就是服务器的容量上限。

4.4 测试长连接（Keep-Alive）效果

很多应用会复用HTTP连接，我们需要看看打开keepalive后的性能提升。wrk默认使用短连接（每次请求都新建TCP连接），如果想模拟长连接，可以加--latency或者通过Lua脚本设置。更简单的方法是使用ab的-k参数，但wrk也有办法。

# 使用Lua脚本强制使用HTTP/1.1并设置Connection: keep-alive

cat > keepalive.lua <

wrk.headers["Connection"] = "keep-alive"

EOF

wrk -t2 -c100 -d30s -s keepalive.lua http://192.168.1.100/test.html

对比两种模式的请求数，一般长连接能提升30%~50%的吞吐量，因为省去了TCP握手和挥手的时间。

4.5 带动态参数的压测（模拟真实API）

如果Nginx是反向代理到后端应用（比如Node.js或PHP），我们需要构造有参数的请求。wrk支持Lua脚本，可以动态生成不同的请求内容。

cat > post.lua <

wrk.method = "POST"

wrk.body = "username=test&password=secret"

wrk.headers["Content-Type"] = "application/x-www-form-urlencoded"

EOF

wrk -t2 -c50 -d20s -s post.lua http://192.168.1.100/api/login

这样就能模拟真实的POST请求了。注意观察Nginx代理层的表现，如果后端返回慢，Nginx可能因为连接池被占满而出现502错误。

五、怎么评估服务器的容量

压测结束后，我们手上有几个关键指标：每秒请求数（QPS）、平均/最大延迟、错误率、CPU/内存使用率。通过这些数据，可以估算出单台Nginx能扛多少流量。

QPS：假如测出来是5000，那意味着理论上每秒能处理5000个请求。如果业务高峰期预计有20000 QPS，那就需要4台机器。

延迟：如果压到5000 QPS时延迟已经超过200ms，那就要考虑优化或者扩容，因为用户感知会变差。

错误率：如果压测中出现大量Connection timed out或500/502，说明架构有瓶颈，可能是Nginx配置不够，或者后端服务跟不上。

资源消耗：压测时用top或者htop看Nginx进程CPU和内存。如果CPU还没用完但请求数上不去，可能是I/O瓶颈（磁盘、网络）。如果内存占用过高，可能配置了过多的缓存。

另外，还要考虑突发流量。比如压测时并发是1000，但实际可能有瞬间2000的并发。最好用siege或wrk的“波浪式”增加连接数，观察系统是否稳定。

六、应用场景、优缺点和注意事项

6.1 应用场景

上线前容量评估：新服务上线前，压测确定需要几台服务器。

配置调优：比如调整Nginx的worker_processes、event模型（epoll/kqueue）、缓冲区大小。压测前后对比效果。

缓存策略：如果Nginx做静态资源缓存，测出缓存命中率对性能的影响。

限流和降级测试：模拟攻击或流量激增，验证限流模块（如limit_req）是否生效。

6.2 优缺点

优点：

提前发现性能瓶颈，避免线上故障。

数据驱动，不用拍脑袋。

工具免费，学习成本低。

缺点：

测试环境与生产环境有差异（比如网络、硬件），数据只能参考。

压测工具本身会消耗资源，需要高性能客户端。

只能测到单机极限，分布式集群还需结合负载均衡测试。

6.3 注意事项

不要在生产环境直接压测，用户会骂你。实在没办法，选低峰期，并且设置压测请求量不要超过当前负载。

控制压测时长：太短数据不稳定，太长可能触发系统保护（比如CPU降频）。一般10~30秒足够，复杂场景可以60秒。

记录多个维度的数据：除了wrk输出，还要收集服务端系统命令如pidstat、netstat、sar，以便定位瓶颈在哪个层次。

重复多次测试：有时网络抖动或者背景进程干扰，单次结果可能不准，取平均值。

注意连接数限制：Linux默认单个进程最大文件句柄是1024，测试前记得ulimit -n 100000，否则会报“Too many open files”。

七、总结

Nginx性能测试不是一次性的活儿，系统迭代后要重新测。通过wrk这样的工具，我们能轻松得出服务器的吞吐量和延迟，从而合理规划容量。记住几个核心点：分清测量对象（静态/动态），控制变量，多维度记录数据，最后用结果指导配置或扩容。希望这篇文章能帮你从“大概能扛多少”变成“精确到每秒多少”，在遇到流量洪峰时心里有底。