基於Locust、Tsung的百萬並發秒殺壓測案例[轉]

編者按：高可用架構分享及傳播在架構領域具有典型意義的文章，本文是 3 月 27 日數人雲運維負責人龐錚在北京“百萬並發”線下活動中的分享記錄。

 

不久前，數人雲聯合清華大學交叉信息研究院 OCP 實驗室通過 10 台 OCP 服務器成功承載了百萬並發 HTTP 請求。

 

此次實驗設立的目標是在物理資源最小值的情況下完成 100 萬並發處理，通過此次實驗，最大化驗證了基於 Mesos 和 Docker 技術的數人雲 DCOS （數據中心操作系統）承載高壓的能力。

 

百萬壓測工具與硬件

壓測工具

 

本次選擇的加壓工具是分布式壓測工具 Locust + Tsung。

 

 

Locust （http://locust.io/）是一個簡單易用的分布式負載測試工具，主要用來對網站進行負載壓力測試。

 

Locust 官網在比較自己與 Apache JMeter 和 Tsung 的優劣中提到

 

我們評估過 JMeter 和 Tsung，它們都還不錯，我們也曾多次使用過 JMeter，但它的測試場景需要通過點擊界面生成比較麻煩，另外它需要給每個測試用戶創建一個線程，因此很難模擬海量並發用戶。

 

Tsung 雖然沒有上面的線程問題，它使用 Erlang 中的輕量級進程，因此可以發起海量並發請求。但是在定義測試場景方面它面臨和 JMeter 同樣的不足。它使用 XML 來定義測試用戶的行為，你可以想象它有多恐怖。如果要查看任何測試結果，你需要你自己去先去整理一堆測試結果日志文件……

 

 

Tsung 是基於 Erlang 的一個開源分布式多協議的負載測試工具，支持 HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP 和 Jabber/XMPP。訪問 http://tsung.erlang-projects.org/ 可以進一步了解。

 

硬件配置

 

OCP 是 Facebook 公司創辦的( Open Compute Project )開放計算項目,目的是利用開源硬件技術推動 IT 基礎設施不斷發展，來滿足數據中心的硬件需求。

 

本次實驗 OCP 硬件配置如下：

 

CPU 類型：主頻 2.20

 

• 雙 CPU 24 核 轉發端

• 雙 CPU 20 核 加壓端

• 雙 CPU 16 核 承壓端

 

內存：DDR3 1600 / 128G

網絡：萬兆網絡

 

這次壓測使用用開源的容器虛擬化技術，將系統和軟件環境打平，把軟件層所有的系統依賴軟件全都封裝在 Docker 中。

 

服務器基礎環境無需配置上面承載服務的復雜依賴環境，而把應用程序和依賴環境都封裝在容器里，在需要遷移的時候非常方便，應用程序的可移植性得到大大提高，非常便於遷移和擴展。

 

如何做百萬壓測

前文已經說到，本次實驗的目標是在物理資源最小值的情況下完成 100 萬並發處理。遇到了以下幾個挑戰：

 

1. 如何加壓到 100 萬？也就是說，用什么加壓方法？

2. 最終需要多少物理資源？架構中每種模塊的處理能力是怎樣的？

 

(圖1：壓測架構圖，點擊圖片可以全屏縮放)

 

紅框內是此次壓測實驗用到的工作集群，而紅框外面的是本次實驗的輔助功能集群。需要說明的是，10 台 OCP 服務器承載 100 萬 HTTP 請求中的 10 台硬件，指的是轉發端加上承壓端的機器，不包括加壓端的機器，因為在真實場景中加壓端是訪問用戶本身。

 

下面對這這次壓測進行詳細說明。

 

基礎環境

 

基礎部署

 

1. 實驗用 OCP 硬件上架、上電、網絡構建、系統安裝；

2. 使用的系統是 CentOS 7.1，需要升級內核升級到 3.19；

3. 使用 Ansible 部署機器其他底層用軟件，包括安裝 Docker 1.9.1（ext4 + overlay），打開系統默認約束(文件句柄，系統內核和中斷優化)等。

 

部署雲集群

 

裝了標准的系統以及 Docker 之后，機器就可以裝數人雲了。龐錚在現場展示了數人雲集群平台的建立步驟，在兩分鍾之內完成安裝。

 

(圖2：承壓端，點擊圖片可以全屏縮放)

 

 

承壓端設計：秒殺項目

雲集群安裝完之后，就可以發布壓測應用了。

 

首先發布承壓端，使用 Nginx + Lua 的組合，它們是高壓系統的常用組合，也是數人雲秒殺項目原生模組，返回結果是動態無緩存數據，保證壓測准確性。由於秒殺模塊不是本文重點，下文只做簡單描述。

 

(圖3：程序返回結果分析)

 

在秒殺模塊中，Time 是自動從服務器取到的時間戳，events 是秒殺服務的數據；event1 是秒殺活動的項目，48 萬是秒殺活動需要持續多少時間。

 

(圖：nginx + Lua 優化)

 

上邊是 Nginx 優化方案，也取自網絡方案。下邊第 2 個框是 Lua 自帶優化，對 Lua 的處理能力至關重要。

 

 

方案 A 壓測

 

承壓端發布完成后，就可以開始部署加壓端。Locust 具有分布式、安裝簡單以及 Web-UI 界面三個特點。

 

(圖：方案A，點擊圖片可全屏縮放)

 

選擇 Locust 在進行測試過程中遇到的問題

 

Locust 不能對多個服務端進行壓測，所以在它的上面加了 Mesos-DNS，用來匯聚壓力提供統一的接口給 Locust slave。Locust 的壓測用力文件是 tasks.py，每個 slave 都需要在啟動前先去 config server 拉一下 tasks.py。

 

緊接着就是轉發層 HA，再接下來就是 Nginx。

 

測試 Locust 步驟

 

• 測試單核性能：約等於 500/s 處理

• 測試單機性能：40 核超線程，約等於1w/s 處理

 

通過測試，發現 Locust 有三個缺點：

 

單核加壓能力低、支持超線程能力差，以及在大量 slave 節點連接的情況下，Master 端不穩定。

 

(圖：Locust-Slave 動用資源)

 

如上圖可以看到，壓測資源分為兩個組，A 組 20 個物理核機器有 20 台，slave 能壓到的能力是 20W/S。B 組 16 個物理核機器有 15 台，可以壓到 12W/S，整個加壓組的能力為 32W/S。

 

(圖：單機 nginx + Lua HOST)

 

壓測第一步

 

得到承壓單機 Nginx + Lua(HOST) 能力是 19.7 萬/s

 

在考慮 HA 的優化，然后是單台測試，最終選擇了keepalive。

 

壓測第二步

 

單機非超線程最后測出來的結果是 22.7 萬，95% 做到 1 秒之內的響應。測試時候發現，HA 的排隊現象非常多，可持續加壓能力非常差，幾分鍾之內就出現嚴重的堵塞。同時，CPU 有幾個是持滿的，說明它的分配不均勻，有一些模塊是需要有統一的模塊調度，導致 HA 無法持續保持高性能處理。

 

單機超線程比非超線程有一些衰減，測出來的結果是 21.9 萬，95%可以做到一秒內響應，但 HA 的排隊請求少很多，CPU 的壓力也平均了很多，測試結果非常穩定。

 

HA 超線程的非 Docker，測出的結果是 27 萬。Docker 情況下確實有一定衰減，可以明顯的看到 99% 的請求在 1 秒內處理了，已經可以達到企業級使用的標准。

    

現在，已知加壓總能力是 32w/s，單機 Nginx + Lua 是 19w/s，轉發層單機 Haproxy 最大能力 27w/s，那么，單機 Nginx + Lua NAT 模式的能力是怎樣的呢？

 

可以看出之前單機 Nginx HOST 網絡模式下發測試結果是 19.7 萬。Nginx 模式加了 HA 再加 NAT 模式，衰減之后是 14.3 萬，CPU 壓力幾乎是100%。

 

 (圖：整體測試結果，點擊圖片可全屏縮放)

 

由於之前使用的 Locust 對於超線程支持以及本身性能問題，無法在現有硬件資源基礎上達到需求，改用 Tsung 進行測試。

 

方案 B 壓測

測試整套文檔可參閱：http://doc.shurenyun.com/practice/tsung_dataman.html 

 

更換成方案 B，繼續進軍百萬並發

 

 (圖：方案B，點擊圖片可全屏縮放)

 

架構圖解釋：Tsung maste 通過 ssh 對 slave 操作，集群之間通訊使用的是 erlang 的 epmd.

 

執行步驟:

 

• 首先將 Tsung 進行 Docker Mesos 化

• 安裝 ssh、安裝 Tsung

• 配置文件 Mesos 化

• 調用數人雲 API 將 Tsung 發布

• API 調用腳本 A

 

方案 B 壓測配置

 

加壓端： Tsung 客戶端加壓機

 

• 數量 20

• cpu 40 核超線程，cpu 消耗 不到瓶頸

• mem 128G

• network 萬兆網絡 

• docker host模式 、docker 下發20個(每台1個)

 

 

Tsung 控制器：本機配置可以縮小很多，測試實體機，隨便選了一個

 

• 數量 1 

• cpu 40 核超線程

• mem 128G

• network 萬兆網絡 

• docker host模式、docker 下發1個

 

轉發端： haproxy

 

• 數量 4

• cpu 48 核超線程、cpu 消耗超高-瓶頸

• mem 128G，內存消耗接近 20g

• network 萬兆網絡 

• docker host 模式、docker 下發 4 個(每台 1 個)

 

承壓 nginx

 

• 數量 6

• CPU 32 核超線程、cpu 消耗超高-瓶頸

• mem 128G、內存消接近耗 10g

• network 萬兆網絡 

• docker nat 模式、docker 下發 48 個(每台 8 個,折算 48w 並發連接能力，處理每台 14w 左右，總數量 80 萬左右)

 

方案 B 詳細報告下載

百萬壓力測試報告：

 

http://qinghua.dataman-inc.com/report.html

 

最終，數人雲在 Tsung 的基礎上順利的完成了百萬壓力測試，業內可以充分參考數人雲此次的百萬並發實踐進行高壓系統的設計。點擊閱讀原文可以了解詳細測試參數。

 

「高可用架構」相關文章

想討論更多互聯網架構壓測技術，請關注公眾號獲取更多文章。轉載請注明來自高可用架構 「ArchNotes」微信公眾號及包含以下二維碼。

 

高可用架構

改變互聯網的構建方式

長按二維碼 訂閱「高可用架構」公眾號