Nginx 实战系列之一：Nginx 压测方法论和性能指标

Nginx 压测方法论和性能指标

Nginx 侧要关注的性能指标

最重要的性能指标如下：

1. Requests per second（RPS）：Nginx 每秒处理的请求数（也就是 QPS）。

• • RPS for HTTP Requests：Nginx 每秒处理的 HTTP 请求数
  
• • RPS for HTTPS Requests（SSL/TLS transactions per second，TPS）：Nginx 每秒处理的 HTTPS 请求数
  

要关注响应数据在 0110KB 的不同情况的表现：

• • 0KB 表示一个空的 HTTP 响应，比如返回 200。
  

2. Connections per Second（CPS）：Nginx 每秒处理的新建连接请求数，包括 HTTP 和 HTTPS。

3. Throughput：吞吐量，反应 Nginx 可以处理的数据量的大小的能力。

4. Latency：响应延迟和延迟分布。

其他关注点如下：

1. 关注 CPU 核数从 1~n 下，Nginx 性能的表现。

利用 taskset，可以将一个 wrk 进程绑定到一个 CPU 核上；可以准确地测试不同 CPU 核下的性能情况

2. 关注 Nginx 的角色是 Web Server 或者反向代理的不同表现。

Nginx 压测时必须要观察 Linux 系统指标

CPU 负载和 CPU 软中断

top 观察 Nginx CPU 消耗情况，同时也要观察每个 CPU 核数的情况。

观察 Nginx 每个 worker 进程的 CPU 消耗是否均匀。正常而言，Nginx 的各个 worker 进程的 CPU 消耗应该都要比较均匀，如果相差 20% 以上，那么就一定存在 CPU 消耗不均的问题。

这里要引入的概念是惊群、accept_mutex、reuseport。

关注 si 软中断的数据，si 将近 100% 就有问题了，某个 CPU 消耗到 100% 还不一定是问题，只有 si 到 100% 才是真正出现性能问题。

这里要引入的概念是 CPU 软中断、中断绑定。

网卡带宽

sar -n DEV 1 100 |grep eth0

观察网卡带宽情况，看网卡带宽是否到了瓶颈。sar 观察数据的时候，一般而言，rxpck/s 和 txpck/s 只需要关注数据而不会存在瓶颈，这个的瓶颈会建立在 CPU 上；而需要关注的是 rxkB/s 和 txkB/s ，这个是判断网卡流量带宽是否有瓶颈的关键指标。

然后可以 ifconfig 查看是否有丢包之类的（overruns 参数），不仅仅是要观察服务端，还要看客户端是否有瓶颈（CPU、网卡带宽）、错误情况等。

每秒建连数

netstat -s |grep active

通过 netstat -s |grep active 获取当前活跃的连接，然后做差值。

连接队列

ss -lnt |grep  80

连接队列如果太小，那么需要调整系统和 Nginx 的配置。

磁盘 IO

iostat 1 |grep sda

sda 是设备名。

关注 wrk 施压端的情况以及施压的最优方案

Nginx 的压测，我们还必须要观察施压端的情况，避免施压端的一些问题，从而造成 Nginx 压力上不去。Nginx 施压端推荐最好的工具就是 wrk。

施压端需要观察 wrk 的每个进程，如果 Nginx 压力压不上去，那么很大概率是出现在了 wrk 上。

需要 top -H 看 wrk 的线程情况，要保证 wrk 的每个线程都不能跑满 100%，这样才能发挥最大的性能。

• • 如果每个线程跑满了，那么 wrk 则无法发挥最大性能，也就是无法提供最高压力。
  
• • 如果每个线程都没跑满，但是 QPS 还是上不去，那么就是 Nginx 这边性能的问题了。
  

wrk 压测的时候，并发数、线程数需要进行调整，要找到一个最合适的性能拐点。

• • 如果 wrk 给的压力太大，一上来就把 Nginx 压出一些瓶颈，那么需要把 wrk 的参数往回调低之后再压，看看曲线中的最高点是哪里，然后这个数据才是最优的数据。
  
• • 如果 wrk 给的压力太小，那么就逐步增加压力，当达到性能瓶颈点后，还需要进行增加压力，看看是否会开始下降，然后依此找到性能拐点，那么这个数据才是最优的数据。
  

wrk 短连接压测 Nginx 的时候，wrk 端的 Linux 系统参数 net.ipv4.tcp_tw_recycle 要设置为 1，让端口复用，否则会出现一些连接错误。

关注 CPU 超线程

禁能、使能 CPU 超线程，在 Nginx 单进程的情况下，并没有明显差异。

实际压测时候， 是否关闭超线程，没有明显差异，这个说明超线程的影响并不大，这个可以作为结论，记住即可。

压测 case 方法

对于 Nginx 的压测，我们一般要分析如下几个 case。

HTTP：

• • 长连接（大包、小包）
  

• • Nginx 打印 access log 日志
  
• • Nginx 不打印 access log 日志
  

• • 短连接（大包、小包）
  

• • Nginx 打印 access log 日志
  
• • Nginx 不打印 access log 日志
  

HTTPS：

• • 长连接（大包、小包）
  

• • Nginx 打印 access log 日志
  
• • Nginx 不打印 access log 日志
  

• • 短连接（大包、小包）
  

• • Nginx 打印 access log 日志
  
• • Nginx 不打印 access log 日志
  

Throughput：

• • 采用长连接、特大包的场景来测吞吐量
  

补充说明：

• • 小包：返回 0KB 数据，return 200 即可
  
• • 大包：返回 1KB 数据，dd 命令模块 1KB 文件大小，具体方法在下面压测中有说明
  
• • 特大包：返回 1MB 数据，只是用来测吞吐量
  

收录于合集 #Nginx

6个

上一篇Nginx 惊群的原因和解决方案下一篇Nginx 实战系列之二： Nginx 优化中在 Nginx 侧和 Linux 系统侧必须要调整优化的参数详细和最佳推荐配置