http://hi.baidu.com/higkoo/item/f3258f02a5afa925a1312d26

前阵子写过一次“关于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核数）

   使用断连接（每次请求新建连接）测试内置的静态页面，结果如下：

http://g.hiphotos.baidu.com/album/pic/item/8644ebf81a4c510fcfa3e0d06059252dd52aa590.jpg性能对比测试" TITLE="Nginx、Tengine、OpenResty 性能对比测试" />

    * 场景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轮测试：

http://h.hiphotos.baidu.com/album/pic/item/b7fd5266d0160924344ea8d1d40735fae7cd3494.jpg性能对比测试" TITLE="Nginx、Tengine、OpenResty 性能对比测试" />

此时Tengine的性能基本同Nginx持平。

    另外，还进行了一些额外的场景。比如对场景E进行手动绑定CPU，性能还能略有提升达到10万QPS。某些场景下Tengine的性能略占优势，但总体而言三者的性能无本质区别。

    之所以场景1里Tengine结果诧异，实际是由于容器配置不同导致。

    本次测试是在“小数据包”、“短连接”的场景下，对3个容器的基本处理能力进行了测量。其后我们应该更关注这3款容器的优点、产品的初衷，进而选择最合适的容器。