原博客地址http://f.dataguru.cn/article-9116-1.html
不久前，數人雲聯合清華大學交叉信息研究院 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,
Postgre
SQL, 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 萬並發處理。遇到了以下幾個挑戰：
如何加壓到 100 萬？也就是說，用什么加壓方法？
最終需要多少物理資源？架構中每種模塊的處理能力是怎樣的？
(圖1：壓測架構圖，點擊圖片可以全屏縮放)
紅框內是此次壓測實驗用到的工作集群，而紅框外面的是本次實驗的輔助功能集群。需要說明的是，10 台 OCP 服務器承載 100 萬 HTTP 請求中的 10 台硬件，指的是轉發端加上承壓端的機器，不包括加壓端的機器，因為在真實場景中加壓端是訪問用戶本身。
下面對這這次壓測進行詳細說明。
基礎環境
基礎部署
實驗用 OCP 硬件上架、上電、網絡構建、系統安裝；
使用的系統是 CentOS 7.1，需要升級內核升級到 3.19；
使用 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 的基礎上順利的完成了百萬壓力測試，業內可以充分參考數人雲此次的百萬並發實踐進行高壓系統的設計。點擊閱讀原文可以了解詳細測試參數。