簡介網站壓力測試以及工具，包含jmeter、ab、fiddler等，以及測試經驗分享。

1. 網站壓力測試與實戰
by Fillano

2. 自介
• 渾名：Fillano / 費大公
• 工作：卑微的網站程式設計師
• 出沒：
▫ http://ithelp.ithome.com.tw/
▫ http://www.plurk.com/Fillano
▫ https://www.facebook.com/Fillano
▫ https://github.com/fillano

3. 最近發生的情境
• 新服務近期將上線
• 由於與關係企業合作，初期就可能有突發的較大
流量
• 老闆要求評估成本與優务（DataCenter or Cloud）
• 老闆要求確認系統可承載新服務

4. 所以
• 只好做壓力測試來確認

5. 什麼是壓力測試？
• 給予系統一定的壓力，觀察系統的反應，以理解：
▫ 系統的瓶頸
▫ 系統在壓力下可能發生的問題
▫ 系統的負載能力
▫ 其他（讓主管安心等）
• 系統包含了硬體與軟體
▫ 軟體：我們寫的網頁程式、伺服器、資料庫、作業
系統等等
▫ 硬體：主機、網路架構等

6. 為什麼要做壓力測試？
• 了解系統在受壓狀況下的潛在問題
• 讓主管安心
• 評估服務的成本
• 規劃未來的需求

7. 什麼不是壓力測試？
• 性能測試不是壓力測試
▫ 例如使用ab來測試系統的性能
▫ 他可以造成夠大的壓力
▫ 但是無法模擬系統真實運行的狀況，所以比較無法
用來評估系統的硬體需求與成本
• 整合測試不是壓力測試
▫ 例如使用selenium、casper.js、fiddler來錄製頁面
操作，然後播放
▫ 這些可以模擬真實操作情況
▫ 但是無法產生足夠的壓力

8. 有什麼工具可以使用？
• 花錢的
▫ HP的LoadRunner
▫ ParaSoft的Load Test
▫ IBM的Rational Performance Tester
▫ 參閱
https://en.wikipedia.org/wiki/Load_and_performanc
e_test_tools
• 免錢的
▫ Apache基金會的Jmeter
▫ OpenSTA
▫ Grinder

9. 為什麼選擇Jmeter
• 免錢
• 成熟
• 可以錄製腳本
• 可以分散測試
• 說不定有一些外掛可以用（ex. snmp…雖然不太
好用）

10. 然後就開始測試了…
• 老闆想試試雲端…
• H雲要簽約才能測試XD
• AWS EC2提供一年的免費試用（最低等級的
instance）
• 二話不說…

11. 之前的壓力測試
• 在封閉環境進行
• 使用多台實體機器
• 主要目的是檢測軟體效能瓶頸
• but

12. 測試對象以及測試工具都放在EC2
• 反正都要用雲端了…
• Amazon提供超大頻寬，然後以量計費（超便宜，
不過H雲更便宜就是了）
• 跟同事一起準備做測試，他負責Jmeter，我負責
系統
• 兩個人各申請一個帳號，就可以免費做測試，歐
耶
• but…

13. 無法收斂測試結果
• 每次結果不一樣，有時候差距很大
• 最好的狀況下，也距離承載目標非常遙遠

14. micro instance的教訓
• 記憶體只有500+MB，可承載的客戶不多
• CPU受限（burst / steal time）
• 測試結果不穩定（看有沒有人跟你搶）
• 不只受測端，連測試端（Jmeter）是否能穩定施
加壓力也無法確定

15. 調整架構
• 為了效能極大化
▫ 伺服器由Apache httpd改成nginx
▫ nginx設定：2 workers, 12000 concurrent / per
worker
▫ php fastcgi + xcache x 100
• 受測端instance改用m1.large
• 測試端還是用micro instance，但是加到八台
• 好像很威了？but

16. 繼續調整架構
• 壓力無法到達目標，壓力不穩定（敗給micro
instance了）
• 資料庫使用micro instance，同樣撐不住，會發生
connection fail
• 老闆要求模擬真實狀況
▫ 服務放在AWS，使用者在台灣
▫ 原本受測端放在美西，測試端在東京
▫ 所以把受測端移到新加坡
▫ 希望這樣會比較接近XD

17. 最終測試架構
• 受測端直接用預計使用的方案
▫ 兩台m1.large做web server
▫ 前面一台AWS的load balancer
▫ 後端一台m1.xlarge做資料庫
• 測試端使用兩台m1.large

18. 測試結果
• 800 concurrent ok
• 同事度假去（沒產出報表，沒測出承載極限）
• 老闆說，時間花夠多了
• 結束（反正到時候要我負責就是XD）

19. 一些概念的問題
• 老闆要求：xxx人同時上線？？？
▫ 同時上線是很模糊的概念
▫ 系統的不同功能，使用的資源可能都不一樣，效能
的表現也不一樣
▫ 所以用同時上線（concurrent）無法較為精確度量
系統的承載力
• 要把測試結果用一致的方式表現，才能做比較
▫ 既然concurrent不好使用，通常我們會用：
requests per second (rps) 或稱作 throughput，作
為比較的標準數據

20. 所以，一個正規的壓力測試過程
• 利用性能測試工具，建立基準數據（baseline）
• (option) 利用fiddler2，記錄系統在單一使用者正
常使用下的一些pattern（在duration中，會有多
少次request，有多少閒置時間等），可以用來評
估壓力測試的腳本與結果是否合乎實際使用狀況
• 使用Jmeter或其他工具，製作測試腳本，進行壓
力測試
• 收集測試數據，判斷是否合乎測試需求
• 解決問題，迴歸測試
• 結束

21. 也可以事後收集數據
• 利用伺服器log，可以統計伺服器端收到的rps
（這次測試，沒有實際產出統計報表…but）
• 利用Amazon提供的使用量報表，可以統計測試
期間的流量（以小時為單位）
• 利用Amazon提供的monitor，也可以確認測試端
以及受測端的系統負載（cpu time, memory, disk
i/o等）

22. 簡單的示範
• 使用fiddler2
• 使用jmeter
▫ 腳本錄製
▫ 進行測試
▫ 怎麼看報表
• 分析伺服器log
• 分析Amazon使用量報表

23. Q&A

24. 參考資料
• http://jmeter.apache.org/
• http://fiddler2.com/
• http://www.prudentman.idv.tw/2011/01/perfor
mance-vs-load-vs-stress-testing.html 跟我的講
法不一樣，不過也可以參考
• http://www.51testing.com 對岸的論壇，主題都
是測試
• 關鍵字「stress test」、「load test」…

25. 銘謝惠顧