前阵子写过一次“关于Linux系统性能瓶颈定位分析(一),Nginx状态页测试(待续)”,当时留下了一个未定位到的瓶颈。
如今,在解开它的同时,顺便也对当下流行的3个WEB服务器进行了一些性能对比。
首先,上述瓶颈是由于单一的端口监听接收请求时存在瓶颈。解决办法:
1、分别监听多个IP
2、监听多个端口
3、修改操作系统内核
本轮测试包括,分别使用Nginx、Tengine和OpenResty测试如下场景(被测服务器的 CPU核数=24):
A、1个服务进程(Master),多个(等同CPU核数)子进程(worker_processes)监听1个IP地址和1个端口
B、1个服务进程(Master),多个(等同CPU核数)子进程(worker_processes)监听所有IP地址(0.0.0.0)和1个端口
C、1个服务进程(Master),1个子进程(worker_processes)监听1个IP地址和1个端口
D、1个服务进程(Master),多个(等同CPU核数)子进程(worker_processes)分别监听各个IP地址的同1个端口
E、多个服务进程(Master),1个子进程(worker_processes)分别监听所有IP地址(0.0.0.0)上的多个端口(等同CPU核数)
使用断连接(每次请求新建连接)测试内置的静态页面,结果如下:
* 场景E的测试过程,使用200个并发无法测出系统的最大能力,故统一提升到300个并发连接。
* 本次测试的最大收获就是:如何让系统发挥最大性能(场景E)
OK,在第1轮测试中:
1、Nginx和OpenResty的性能基本相当,OpenResty略差
2、Tengine除了在场景C性能出众之外,其它场景均垫底
这个结果大出意料和叔度沟通后,可能同测试场景和Tengine自动绑定CPU亲缘性的设定有关。比如:场景C是单进程单IP和单端口,结果Tengine的性能即明显高于其它。而多进程多IP多端口时Tengine即是最差的,场景E测试Tengine时所有软中断的使用都集中在最后一颗CPU核上,而其它则分布到4个CPU上(被测试服务器网卡有4队列)。
SO,我们关闭Tengine的自动绑定CPU亲缘性功能(worker_cpu_affinity off;),进行第2轮测试:
此时Tengine的性能基本同Nginx持平。
另外,还进行了一些额外的场景。比如对场景E进行手动绑定CPU,性能还能略有提升达到10万QPS。某些场景下Tengine的性能略占优势,但总体而言三者的性能无本质区别。
之所以场景1里Tengine结果诧异,实际是由于容器配置不同导致。
本次测试是在“小数据包”、“短连接”的场景下,对3个容器的基本处理能力进行了测量。其后我们应该更关注这3款容器的优点、产品的初衷,进而选择最合适的容器。