不错,去看看中文图书全场满【99】元赠畅销书。。。

NGINX 1.9.1 支持socket分片提升性能

NGINX发布版1.9.1介绍了新的特性,支持socket的SO_REUSEPORT选项,这个选项在许多操作系统的新版本有效,包括DragonFly BSD和Linux(3.9+内核)。
这个选项允许多个socket监听同个IP地址和端口的组合。内核负载均衡这些进来的sockets连接,将这些socket有效的分片。

这个socket的SO_REUSEPORT选项已经有许多现实世界的应用。对NGINX而言,它通过分布进程上的连接以提升性能。

正如下图所描述的,当SO_REUSEPORT选项没开启时,连接进来时监听socket默认会通知某个进程。如果您包含了accept_mutex off这个指令,
此时会唤醒所有的工作进程,它们将为了得到它产生竞争。这就是所谓的惊群现象。
(小解释下:如果使用epoll且不用锁,当监听端口有读操作时,是会产生惊群现象的)

启用SO_REUSEPORT选项后,每个进程将有个独立的监听socket。内核决定哪个是有效的socket(进程)得到这个连接。
这样做降低了延迟并提高了工作进程的性能,它也意味着工作进程在准备处理它们前被赋予了新的连接。

配置socket分片
要开启SO_REUSEPORT选项,将新的参数reuseport加到listen指令的后面,像以下例子这样:
http {
server {
listen 80 reuseport;
server_name localhost;

}
}
包含这个reuseport参数后将禁用这个监听socket的accept_mutex,因为锁变得多余了。如果你不想用reuseport在端口上设置accept_mutex仍然是值得做的。

基准测试性能的提升

我在4个NGINX工作进程36核AWS实例上跑了wrk基准测试,我的客户端和NGINX都在本地上,并且让NGINX只返回OK字符串。
我比较了3种NGINX配置:accept_mutex on(默认),accept_mutex off,还有reuseport。
如图所现,reuseport每秒提升了2到3倍的请求,同时降低了延迟和stdev指标。

我也跑了一个更加真实的测试,将客户端和NGINX分离到不同的主机并且让NGINX返咽一个HTML页面文件。正如图表所显示的,带reuseport的降低的延迟跟上面的测试很接近,
并且stdev的也是。其它的测试结果也是很令人鼓舞的。由于reuseport,负载更加均衡的分配到各工作进程。在默认情况下(accept_mutex on),一些工作进程表现的各加均衡,
accept_mutex off情况下则有些表现的高低不下。
Latency (ms) Latency stdev (ms) CPU Load
Default 15.65 26.59 0.3
accept_mutex off 15.59 26.48 10
reuseport 12.35 3.15 0.3

致谢
感谢Sepherosa Ziehau和Yingqi Lu,他们在NGINX项目中使用了SO_REUSEPORT选项。NGINX团队借鉴他们的方法,并在NGINX创建了我们觉得更理想的方案。

译文来源:http://nglua.com/docs/sharding.html
原文:Socket Sharding in NGINX Release 1.9.1

评论一下...

电子邮件地址不会被公开。 必填项已用*标注