網站壓力測試與實戰
Upcoming SlideShare
Loading in...5
×
 

網站壓力測試與實戰

on

  • 5,749 views

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

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

Statistics

Views

Total Views
5,749
Views on SlideShare
5,732
Embed Views
17

Actions

Likes
23
Downloads
82
Comments
1

1 Embed 17

http://www.plurk.com 17

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

網站壓力測試與實戰 網站壓力測試與實戰 Presentation Transcript

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