關於Linux系統性能瓶頸定位分析（一），Nginx狀態頁測試
-
使用場景：
Nginx對外提供介面服務，本文以Nginx的狀態頁（stub_status）為例。
-
需要解決的問題：
定位效能瓶頸，並調優
-
測試方法
使用約40臺測試機向一臺Nginx伺服器併發訪問
-
伺服器配置
DELL PowerEdge R510
CentOS 5.8 / Linux 2.6.18-308.8.2.el5 x86_64
Two Quad-Core Xeon E5606 @ 2.13GHz with L2 cache = 1MiB & L3 cache = 8MiB
System Memory 64GiB with width = 64 bits & clock = 1333MHz (0.8ns)
Broadcom BCM5716 driver=bnx2 driverversion=2.2.1j firmware=6.2.12 bc 5.2.3 speed=1Gbit/s
-
ulimit 配置
Firewall is stopped.
getenforce = Disabled
-
sysctl 配置
-
Nginx配置
nginx.conf定製配置項，其它全預設
worker_processes 8;
worker_connections 81920;
location = /status { # 測試此介面
stub_status on;
access_log off;
}
-
測試結果，伺服器壓力
從top結果我們可以看出：
-
未發現cpu有瓶頸
-
記憶體大量剩餘
-
系統負載很低
-
沒有磁碟IO
-
網絡卡軟中斷未出現瓶頸（頻寬和fps也未到瓶頸）
-
測試結果，效能體現
此圖我們可以看出：
-
逐步加壓，約200個併發訪問時，每秒事務數到頂
-
隨併發數的增加，響應時間隨之變長，但每秒響應數量並未同比增加
-
最終Nginx每秒成功響應2萬次請求
大概3年前的伺服器（Lenovo WQ R510 G6），1顆4核CPU/4G記憶體/146G-SAS。相同的測試環境下，都能每秒響應近4萬次請求。
=========================================================================================================
Nginx、Tengine、OpenResty 效能對比測試
如今，在解開它的同時，順便也對當下流行的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款容器的優點、產品的初衷，進而選擇最合適的容器。