基於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」公眾號及包含以下二維碼。

 

高可用架構

改變互連網的構建方式

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

 

 

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