Nginx启用reuseport[转载]

案例

这两天做一个http测试，客户端使用一台8核16G的虚机，服务器使用8台8核16G的虚机，服务器挂在负载均衡后端。
客户端使用wrk打流
服务器开启nginx，返回 200 ok
测试结果发现服务器nginx的cpu利用率恨不均匀，后来查到有reuseport这个参数，放在listen后面

listen 80 default_server reuseport;

增了了试验了下，果然好用。
下图是对比，上面是不开启reuseport，可以看到cpu利用率在20-40%，而开启了，cpu利用率只有12%了。

http请求

https请求

原理

未使能 reuseport

一个单独的监听socket通知工作进程接入的连接，并且每个工作线程都试图获得连接。

使能 reuseport

系统内核决定哪一个有效的socket监听器（通过隐式的方式，给哪一个工作进程）获得连接。这可以减少工作进程之间获得新连接时的封锁竞争

reuseport的基准性能测试

在一个36核的AWS实例运行wrk基准测试工具，测试4个NGINX工作进程。为了减少网络的影响，客户端和NGINX都运行在本地，并且让NGINX返回OK字符串而不是一个文件。我比较三种NGINX配置：默认（等同于accept_mutex on），accept_mutex off和reuseport。如图所示，reuseport的每秒请求是其余的两到三倍，同时延迟和延迟标准差也是减少的。

总结

使用锁进行负载均衡的方式已经不推荐使用了，Nginx 在 1.11.3 之后也默认不开启 accept_mutex 。

Linux 3.9 引入了 SO_REUSEPORT 支持，Linux 4.5 引入了 EPOLLEXCLUSIVE 支持。只要开启 reuseport 或者升级到 Linux 4.5+，就不用开启accept_mutex。

HTTP压测工具之wrk

wrk是一款简单的HTTP压测工具,托管在Githu上,https://github.com/wg/wrk.
wrk 的一个很好的特性就是能用很少的线程压出很大的并发量.

安装

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

如果编译过程中出错:

src/wrk.h:11:25: fatal error: openssl/ssl.h: No such file or directory  
#include <openssl/ssl.h>

则需要安装openssl,使用sudo apt-get install libssl-dev或 sudo yum install openssl-devel安装即可,最后编辑etc/profile配置环境变量。由于笔者使用的是阿里云centos7,相关依赖都已经存在了,所以可以直接使用。

使用

wrk -t12 -c100 -d30s http://www.baidu.com

这段脚本的输出是:

[root@jerrik /]# wrk -t12 -c100 -d30s http://www.baidu.com  
Running 30s test @ http://www.baidu.com
  12 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   211.76ms  304.92ms   1.97s    88.17%
    Req/Sec    72.93     68.72   797.00     90.97%
  23725 requests in 30.05s, 347.47MB read
  Socket errors: connect 0, read 48, write 0, timeout 50
Requests/sec:    789.57
Transfer/sec:     11.56MB

注意：一般线程数不宜过多. 核数的2到4倍足够了. 多了反而因为线程切换过多造成效率降低. 因为 wrk 不是使用每个连接一个线程的模型, 而是通过异步网络 io 提升并发量. 所以网络通信不会阻塞线程执行. 这也是 wrk 可以用很少的线程模拟大量网路连接的原因. 而现在很多性能工具并没有采用这种方式, 而是采用提高线程数来实现高并发. 所以并发量一旦设的很高, 测试机自身压力就很大. 测试效果反而下降.

参数解释:

12 threads and 100 connections:
总共是12个线程,100个连接(不是一个线程对应一个连接)
latency和Req/Sec:
代表单个线程的统计数据,latency代表延迟时间,Req/Sec代表单个线程每秒完成的请求数，他们都具有平均值, 标准偏差, 最大值, 正负一个标准差占比。一般我们来说我们主要关注平均值和最大值. 标准差如果太大说明样本本身离散程度比较高. 有可能系统性能波动很大.
23725 requests in 30.05s, 347.47MB read
在30秒之内总共有23725个请求,总共读取347.47MB的数据
Socket errors: connect 0, read 48, write 0, timeout 50
总共有48个读错误,50个超时.
Requests/sec和Transfer/sec
所有线程平均每秒钟完成了789.57个请求,每秒钟读取11.56MB数据量

如果想看看响应时间的分布,可以增加--latency:
wrk -t12 -c100 -d30s --latency http://www.baidu.com

结果为:

[root@jerrik ~]# wrk -t12 -c100 -d30s --latency http://www.baidu.com 
Running 30s test @ http://www.baidu.com
  12 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   204.30ms  287.90ms   1.97s    88.61%
    Req/Sec    71.43     67.59   810.00     89.77%
  Latency Distribution
     50%   14.76ms
     75%  296.79ms
     90%  545.03ms
     99%    1.40s 
  23676 requests in 30.03s, 346.84MB read
  Socket errors: connect 0, read 42, write 0, timeout 46
Requests/sec:    788.29
Transfer/sec:     11.55MB

说明有50%的请求在14.76ms之内,90%在545.03ms之内。