閘道器服務：zuul與nginx的效能測試對比

案例一. Nginx單工作執行緒，單檔案路徑訪問測試

檔案內容僅6個數字：123456

測試命令：ab -c 100 -n 500000 127.0.0.1:80/html/test.html

可以看到每秒併發：32566 req

使用top命令，可以看到cpu使用情況： ab cpu:99%    nginx cpu:99%

 

案例二. Nginx作為入口閘道器，將請求轉發至業務服務，這裡為了方便，直接使用nginx作為業務服務

第一級接入層閘道器nginx轉發配置，埠80：

server {
        listen    80;
        location / {
                proxy_pass   http://127.0.0.1:8080/;
        }
}

轉發至第二級http業務服務8080，nginx配置如下，這裡簡單訪問本地檔案：

server {
        listen    8080;
        location /html/ {
                alias  /data/service/gw/html/;
                expires 7d;
       }
}

命令：ab -c 100 -n 500000 127.0.0.1:80/html/test.html

可以看到併發同樣可以達到34497req

而負載情況：

閘道器nginx，用了兩個工作執行緒，總cpu佔用率：95.7%+95.3%=191%

而本地檔案訪問nginx，僅一個工作執行緒，cpu佔用率：90%

 

案例三：將第一級閘道器替換成zuul,第二級仍然轉發至業務http nginx伺服器，業務請求簡單訪問本地檔案

由於此時zuul是多執行緒的架構，很依賴cpu資源大小，這裡先做第一組配置測試：8u cpu, 16GB 記憶體。

zuul的執行緒配置：最小min-space-threads:100，最大max-threads:200

使用命令： ab -c 200 -n 300000 127.0.0.1:8000/api/html/test.html 

併發數大約在12860req/s

穩定之後整個系統的使用者空間加核心空間的總負載基本約77.7%=58.7%+19%

記憶體使用情況如下：

可以分析到此時系統很忙碌，基本是滿負荷在執行，瓶頸在cpu資源的競爭上。

 

 

案例四：將案例三的情況做第二組配置的測試：12u cpu, 24GB 記憶體。

ab -c 100 -n 500000 127.0.0.1:8000/api/html/test.html

併發資料果然有對應核數的比例提升：19113req/s

此時系統也處於比較高的負載：73.6=60.1+13.5，其中使用者空間同樣佔到大約60.1%的負載

而記憶體還是有很多富餘的，效能瓶頸同樣是在cpu資源的競爭上。

總結：

在cpu資源相對充足的情況下，zuul的效能也是不俗的，單個例項同樣可以達到1W+，cpu的佔用大概在500%。

這裡可能還可以用jvm等引數進行調優，也歡迎在此基礎之上效能調優做得更細緻的朋友前來指教，但總體效能指標相差不會太遠，而zuul是可以很方便的支援多個例項橫向擴充套件以及路由的負載均衡的，在分散式的架構演進上面作為閘道器層是一個比較不錯的選擇。

 

最後附上zuul的jmc效能監控圖：

執行緒情況

 

也可以從jmc的執行緒檢視中可以觀察到，有大量的tomcat的任務執行緒在競爭任務佇列的資源，並處於等待當中。

cpu佔用率最多的執行緒當然還是屬於網路io的連線執行緒，以及讀寫資料事件執行緒。

記憶體使用情況：