Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
網站壓力測試與實戰
by Fillano
自介
• 渾名:Fillano / 費大公
• 工作:卑微的網站程式設計師
• 出沒:
▫ http://ithelp.ithome.com.tw/
▫ http://www.plurk.com/Fillano
▫ https://www.fa...
最近發生的情境
• 新服務近期將上線
• 由於與關係企業合作,初期就可能有突發的較大
流量
• 老闆要求評估成本與優务(DataCenter or Cloud)
• 老闆要求確認系統可承載新服務
所以
• 只好做壓力測試來確認
什麼是壓力測試?
• 給予系統一定的壓力,觀察系統的反應,以理解:
▫ 系統的瓶頸
▫ 系統在壓力下可能發生的問題
▫ 系統的負載能力
▫ 其他(讓主管安心等)
• 系統包含了硬體與軟體
▫ 軟體:我們寫的網頁程式、伺服器、資料庫、作業
系統等...
為什麼要做壓力測試?
• 了解系統在受壓狀況下的潛在問題
• 讓主管安心
• 評估服務的成本
• 規劃未來的需求
什麼不是壓力測試?
• 性能測試不是壓力測試
▫ 例如使用ab來測試系統的性能
▫ 他可以造成夠大的壓力
▫ 但是無法模擬系統真實運行的狀況,所以比較無法
用來評估系統的硬體需求與成本
• 整合測試不是壓力測試
▫ 例如使用selenium、c...
有什麼工具可以使用?
• 花錢的
▫ HP的LoadRunner
▫ ParaSoft的Load Test
▫ IBM的Rational Performance Tester
▫ 參閱
https://en.wikipedia.org/wiki...
為什麼選擇Jmeter
• 免錢
• 成熟
• 可以錄製腳本
• 可以分散測試
• 說不定有一些外掛可以用(ex. snmp…雖然不太
好用)
然後就開始測試了…
• 老闆想試試雲端…
• H雲要簽約才能測試XD
• AWS EC2提供一年的免費試用(最低等級的
instance)
• 二話不說…
之前的壓力測試
• 在封閉環境進行
• 使用多台實體機器
• 主要目的是檢測軟體效能瓶頸
• but
測試對象以及測試工具都放在EC2
• 反正都要用雲端了…
• Amazon提供超大頻寬,然後以量計費(超便宜,
不過H雲更便宜就是了)
• 跟同事一起準備做測試,他負責Jmeter,我負責
系統
• 兩個人各申請一個帳號,就可以免費做測試,歐
...
無法收斂測試結果
• 每次結果不一樣,有時候差距很大
• 最好的狀況下,也距離承載目標非常遙遠
micro instance的教訓
• 記憶體只有500+MB,可承載的客戶不多
• CPU受限(burst / steal time)
• 測試結果不穩定(看有沒有人跟你搶)
• 不只受測端,連測試端(Jmeter)是否能穩定施
加壓力也無法...
調整架構
• 為了效能極大化
▫ 伺服器由Apache httpd改成nginx
▫ nginx設定:2 workers, 12000 concurrent / per
worker
▫ php fastcgi + xcache x 100
•...
繼續調整架構
• 壓力無法到達目標,壓力不穩定(敗給micro
instance了)
• 資料庫使用micro instance,同樣撐不住,會發生
connection fail
• 老闆要求模擬真實狀況
▫ 服務放在AWS,使用者在台灣
▫...
最終測試架構
• 受測端直接用預計使用的方案
▫ 兩台m1.large做web server
▫ 前面一台AWS的load balancer
▫ 後端一台m1.xlarge做資料庫
• 測試端使用兩台m1.large
測試結果
• 800 concurrent ok
• 同事度假去(沒產出報表,沒測出承載極限)
• 老闆說,時間花夠多了
• 結束(反正到時候要我負責就是XD)
一些概念的問題
• 老闆要求:xxx人同時上線???
▫ 同時上線是很模糊的概念
▫ 系統的不同功能,使用的資源可能都不一樣,效能
的表現也不一樣
▫ 所以用同時上線(concurrent)無法較為精確度量
系統的承載力
• 要把測試結果用一致...
所以,一個正規的壓力測試過程
• 利用性能測試工具,建立基準數據(baseline)
• (option) 利用fiddler2,記錄系統在單一使用者正
常使用下的一些pattern(在duration中,會有多
少次request,有多少閒置...
也可以事後收集數據
• 利用伺服器log,可以統計伺服器端收到的rps
(這次測試,沒有實際產出統計報表…but)
• 利用Amazon提供的使用量報表,可以統計測試
期間的流量(以小時為單位)
• 利用Amazon提供的monitor,也可以...
簡單的示範
• 使用fiddler2
• 使用jmeter
▫ 腳本錄製
▫ 進行測試
▫ 怎麼看報表
• 分析伺服器log
• 分析Amazon使用量報表
Q&A
參考資料
• http://jmeter.apache.org/
• http://fiddler2.com/
• http://www.prudentman.idv.tw/2011/01/perfor
mance-vs-load-vs-str...
銘謝惠顧
Upcoming SlideShare
Loading in …5
×

網站壓力測試與實戰

12,304 views

Published on

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

Published in: Technology

網站壓力測試與實戰

  1. 1. 網站壓力測試與實戰 by Fillano
  2. 2. 自介 • 渾名:Fillano / 費大公 • 工作:卑微的網站程式設計師 • 出沒: ▫ http://ithelp.ithome.com.tw/ ▫ http://www.plurk.com/Fillano ▫ https://www.facebook.com/Fillano ▫ https://github.com/fillano
  3. 3. 最近發生的情境 • 新服務近期將上線 • 由於與關係企業合作,初期就可能有突發的較大 流量 • 老闆要求評估成本與優务(DataCenter or Cloud) • 老闆要求確認系統可承載新服務
  4. 4. 所以 • 只好做壓力測試來確認
  5. 5. 什麼是壓力測試? • 給予系統一定的壓力,觀察系統的反應,以理解: ▫ 系統的瓶頸 ▫ 系統在壓力下可能發生的問題 ▫ 系統的負載能力 ▫ 其他(讓主管安心等) • 系統包含了硬體與軟體 ▫ 軟體:我們寫的網頁程式、伺服器、資料庫、作業 系統等等 ▫ 硬體:主機、網路架構等
  6. 6. 為什麼要做壓力測試? • 了解系統在受壓狀況下的潛在問題 • 讓主管安心 • 評估服務的成本 • 規劃未來的需求
  7. 7. 什麼不是壓力測試? • 性能測試不是壓力測試 ▫ 例如使用ab來測試系統的性能 ▫ 他可以造成夠大的壓力 ▫ 但是無法模擬系統真實運行的狀況,所以比較無法 用來評估系統的硬體需求與成本 • 整合測試不是壓力測試 ▫ 例如使用selenium、casper.js、fiddler來錄製頁面 操作,然後播放 ▫ 這些可以模擬真實操作情況 ▫ 但是無法產生足夠的壓力
  8. 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. 9. 為什麼選擇Jmeter • 免錢 • 成熟 • 可以錄製腳本 • 可以分散測試 • 說不定有一些外掛可以用(ex. snmp…雖然不太 好用)
  10. 10. 然後就開始測試了… • 老闆想試試雲端… • H雲要簽約才能測試XD • AWS EC2提供一年的免費試用(最低等級的 instance) • 二話不說…
  11. 11. 之前的壓力測試 • 在封閉環境進行 • 使用多台實體機器 • 主要目的是檢測軟體效能瓶頸 • but
  12. 12. 測試對象以及測試工具都放在EC2 • 反正都要用雲端了… • Amazon提供超大頻寬,然後以量計費(超便宜, 不過H雲更便宜就是了) • 跟同事一起準備做測試,他負責Jmeter,我負責 系統 • 兩個人各申請一個帳號,就可以免費做測試,歐 耶 • but…
  13. 13. 無法收斂測試結果 • 每次結果不一樣,有時候差距很大 • 最好的狀況下,也距離承載目標非常遙遠
  14. 14. micro instance的教訓 • 記憶體只有500+MB,可承載的客戶不多 • CPU受限(burst / steal time) • 測試結果不穩定(看有沒有人跟你搶) • 不只受測端,連測試端(Jmeter)是否能穩定施 加壓力也無法確定
  15. 15. 調整架構 • 為了效能極大化 ▫ 伺服器由Apache httpd改成nginx ▫ nginx設定:2 workers, 12000 concurrent / per worker ▫ php fastcgi + xcache x 100 • 受測端instance改用m1.large • 測試端還是用micro instance,但是加到八台 • 好像很威了?but
  16. 16. 繼續調整架構 • 壓力無法到達目標,壓力不穩定(敗給micro instance了) • 資料庫使用micro instance,同樣撐不住,會發生 connection fail • 老闆要求模擬真實狀況 ▫ 服務放在AWS,使用者在台灣 ▫ 原本受測端放在美西,測試端在東京 ▫ 所以把受測端移到新加坡 ▫ 希望這樣會比較接近XD
  17. 17. 最終測試架構 • 受測端直接用預計使用的方案 ▫ 兩台m1.large做web server ▫ 前面一台AWS的load balancer ▫ 後端一台m1.xlarge做資料庫 • 測試端使用兩台m1.large
  18. 18. 測試結果 • 800 concurrent ok • 同事度假去(沒產出報表,沒測出承載極限) • 老闆說,時間花夠多了 • 結束(反正到時候要我負責就是XD)
  19. 19. 一些概念的問題 • 老闆要求:xxx人同時上線??? ▫ 同時上線是很模糊的概念 ▫ 系統的不同功能,使用的資源可能都不一樣,效能 的表現也不一樣 ▫ 所以用同時上線(concurrent)無法較為精確度量 系統的承載力 • 要把測試結果用一致的方式表現,才能做比較 ▫ 既然concurrent不好使用,通常我們會用: requests per second (rps) 或稱作 throughput,作 為比較的標準數據
  20. 20. 所以,一個正規的壓力測試過程 • 利用性能測試工具,建立基準數據(baseline) • (option) 利用fiddler2,記錄系統在單一使用者正 常使用下的一些pattern(在duration中,會有多 少次request,有多少閒置時間等),可以用來評 估壓力測試的腳本與結果是否合乎實際使用狀況 • 使用Jmeter或其他工具,製作測試腳本,進行壓 力測試 • 收集測試數據,判斷是否合乎測試需求 • 解決問題,迴歸測試 • 結束
  21. 21. 也可以事後收集數據 • 利用伺服器log,可以統計伺服器端收到的rps (這次測試,沒有實際產出統計報表…but) • 利用Amazon提供的使用量報表,可以統計測試 期間的流量(以小時為單位) • 利用Amazon提供的monitor,也可以確認測試端 以及受測端的系統負載(cpu time, memory, disk i/o等)
  22. 22. 簡單的示範 • 使用fiddler2 • 使用jmeter ▫ 腳本錄製 ▫ 進行測試 ▫ 怎麼看報表 • 分析伺服器log • 分析Amazon使用量報表
  23. 23. Q&A
  24. 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. 25. 銘謝惠顧

×