基於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」微信公衆號及包含如下二維碼。

 

高可用架構

改變互聯網的構建方式

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