壓力測試大冒險：解鎖應用程式的隱藏性能之謎

Modern Web Conference 2023
本次議程中將全面介紹並分享壓力測試的基本觀念和理念。

首先，我們將深入探究壓力測試的重要性，探討如何明確定義測試目標，並闡述測試如何在應用程式中發現脆弱點，確保系統的穩定性與可靠性。

接著，我們將著重探討壓力測試與服務等級協定（SLA）之間的密不可分聯繫，闡明在確保系統滿足用戶期望方面，壓力測試所扮演的關鍵角色。

最後，我們將透過實際案例與工具演示，深入探討如何精心設計壓力測試場景，模擬各種負載情境，以揭示應用程式的性能極限。這三個核心觀念將引導參與者深入理解壓力測試，揭開優越性能的秘密，同時突顯壓力測試在確保SLA達成中的關鍵作用。

Transcript

1. Marcus @ MWC 2023
   壓力測試大冒險：解鎖應用程式
   的隱藏性能之謎
   

   View Slide

2. 2
   I’m
   ▸
   後端打雜工
   ▸
   #挑戰自我 #分享 #可觀測性
   分享經驗
   - COSCUP、MOPCON、DevopsDays
   - .NET Conf、Will 保哥線上技術分享
   - 微軟活動 : 打造化繁為簡的雲原生平台
   Hello!
   m@rcus 學習筆記
   Marcus
   

   View Slide

3. 本次分享旨在與聽眾分享本人過往對於壓力測試議題的
   個人觀點，本場不會談論任何技術細節，期待看到大量
   技術、工具實務細節的朋友們，可能會大失所望。為不
   耽誤您的青春，請趁其他教室關門前前往。
   3
   WARNING
   #新人（Newcomer） #開發者（Developers） #維運者（Operators）
   

   View Slide

4. 4
   Agenda
   1
   Performance Testing
   工具選擇
   Takeaway
   4
   3
   2
   傳統監控工具的挑戰
   Credit to : https://www.behance.net/diegocarbonell
   

   View Slide

5. 6
   系統上線後，然後呢 ?
   

   View Slide

6. 上線後的挑戰 : 維運
   7
   Credit to : https://marcus116.blogspot.com/2020/03/tgonext-monolith-soa-microservices-system-architecture-evolution.html
   複雜應用程式的挑戰 可視化的挑戰 大規模用戶負載的挑戰
   Monitor Dashboard High concurrency
   

   View Slide

7. 8
   流量 10 倍，會發生什麼事 ?
   Credit to https://kang0729.pixnet.net/blog/post/114597509
   

   View Slide

8. 大規模用戶負載的挑戰
   9
   Credit to : https://marcus116.blogspot.com/2020/03/tgonext-monolith-soa-microservices-system-architecture-evolution.html
   

   View Slide

9. 大規模用戶負載的挑戰
   10
   Credit to : https://marcus116.blogspot.com/2020/03/tgonext-monolith-soa-microservices-system-architecture-evolution.html
   

   View Slide

10. 大規模用戶負載的挑戰
    11
    Credit to : https://marcus116.blogspot.com/2020/03/tgonext-monolith-soa-microservices-system-architecture-evolution.html
    

    View Slide

11. 12
    流量 10 倍，會發生什麼事 ?
    RD 會受傷
    Credit to : https://game.udn.com/game/story/10453/3232490
    

    View Slide

12. 13
    #大家的期待
    Credit to : https://memes.tw/maker/template/39894
    

    View Slide

13. 14
    What can we do ?
    反思 : 系統應具備什麼樣的特性
    

    View Slide

14. RAS : Reliability, Availability & Serviceability
    • 可靠性 Reliability
    • 特定的時間內，系統正常執行成功的機率(失敗)
    • 平均無故障時間 (MTBF) : 20天10小時12分鐘
    • 可用性 High Available
    • 正常運行時間的百分比(成功)
    • 衡量指標 : SLA 99.90%
    • 可維護性 Serviceability
    • 系統修復或維護的簡單性和速度
    • 出現問題時診斷系統的各種方法。及早發現故障可以減少或避免系統停機
    16
    Credit to : https://en.wikipedia.org/wiki/Reliability,_availability_and_serviceability
    

    View Slide

15. 17
    Make it work
    Make it right
    Make it fast
    - [質] 系統活著
    - [質] 功能正常
    - [量] 性能佳 (Performance)
    

    View Slide

16. 18
    Performance
    關於性能
    

    View Slide

17. Performance
    19
    Frontend Performance
    Backend Performance
    Credit to : https://grafana.com/blog/2023/04/03/frontend-vs.-backend-how-to-plan-your-performance-testing-strategy/
    

    View Slide

18. 20
    What makes me recognize that
    I have a performance problem ?
    反思 : 如何知道應用程式有性能議題
    

    View Slide

19. Application Slow : Single Task
    21
    Credit to : https://www.youtube.com/watch?app=desktop&v=f5VgIRThhkA
    

    View Slide

20. Application Slow : System slow
    22
    Credit to : https://www.youtube.com/watch?app=desktop&v=f5VgIRThhkA
    

    View Slide

21. Cloud : Scaling strategy
    23
    Credit to : https://www.binadox.com/blog/scalability-in-cloud-computing/
    

    View Slide

22. Develop : Commit Code
    24
    Credit to : https://twitter.com/8Zmsz/status/1399706303233019905
    

    View Slide

23. Architecture : 系統架構上的瓶頸
    25
    Distributed
    systems
    Credit to : https://read01.com/GPjeDDG.html
    

    View Slide

24. 目的 : 了解未知及帶來的風險
    26
    Credit to : https://engoo.com.tw/blog/%E4%B8%BB%E9%A1%8C%E9%A1%9E/know-known-unknow-unknown/
    

    View Slide

25. 27
    Performance Testing
    解開應用程式性能謎題
    

    View Slide

26. ” In software engineering,
    performance testing is in general
    a testing practice performed to
    determine how a system performs in
    terms of responsiveness and stability
    under a particular workload ”
    28
    - Wikipedia
    

    View Slide

27. Testing Types and Strategies
    • 效能測試！= 壓力測試
    • 非功能性需求 (Non-function required)
    • less traffic ≠ no performance problems
    • troubleshooting and debugging
    • 不同目標跟方式
    29
    

    View Slide

28. 30
    Testing Types and Strategies
    Spike : 驗證系統在活動突然、短暫和大量增加的情況下的行為
    Smoke : 驗證腳本是否有效以及系統在最小負載下是否能夠充分執行
    Average Load : 評估系統在預期正常條件下的效能
    Stress : 評估當負載超過預期平均值時系統在其極限下的表現
    Soak : 評估系統在較長時間內的可靠性和性能
    Breakpoint : 逐漸增加負載，以確定系統的容量限制
    Credit to : Load test types
    

    View Slide

29. 33
    How do we begin ?
    如何開始
    

    View Slide

30. 起手式 : Google Performance Tools
    35
    

    View Slide

31. Performance Tools
    36
    

    View Slide

32. 37
    Yes, but not
    可以說中文嗎 ?
    

    View Slide

33. ”專案開始之初，首重看見全貌”
    38
    - Ruddy Lee 老師
    

    View Slide

34. 測試計畫 : Testing Plan
    39
    Business
    Needs
    Stakeholder
    Requirements
    Test Scenario
    Execution
    (Test case)
    Result &
    Reporting
    

    View Slide

35. Business Needs : Defining Goals
    • Why : 為什麼需要測試
    • ex : 了解系統目前狀況
    • Define goals and required
    • ex : 順利度過雙11
    • ex : 提升應用程式性能 20%
    • 結果是否符合預期
    • 監控與追蹤成效
    • 量化數據 & Test Report
    41
    Credit to : 我是誰 我在哪 我要去哪裡
    

    View Slide

36. Business Needs : Defining Goals
    SLA
    Service Level Agreement
    SLOs
    SLIs
    Service-Level Indicator
    Service-Level Indicator
    Service-Level Indicator
    Credit to : https://k6.io/modern-load-testing-for-engineering-teams/
    

    View Slide

37. Business Needs : Defining Goals
    SLA
    99% latency < 300ms
    SLOs
    SLIs
    99% latency < 100ms
    99% latency > 150ms
    Latency of successful (http 200)
    99% latency < 200 ms
    Credit to : https://k6.io/modern-load-testing-for-engineering-teams/
    

    View Slide

38. 設計壓力測試場景
    • 為了在過程中獲得 有意義的數據，制定清晰的測試場景
    • 場景設計 : 定義你想要測試的情境，並設置相關環境。
    • 合適的測試 : 定義應用程式的合理負載，以使其能夠應對不同情況。
    • 準備測試數據 : 製作測試用的基礎數據，以生成更加真實的測試場景
    44
    

    View Slide

39. 測試場景 : 以打卡系統為例
    45
    6:00 AM 12:00 PM 06:00 PM 00:00 AM
    N
    N+1k
    N+2k
    N+3k
    N+4k
    Insight ?
    

    View Slide

40. 測試場景 : 以打卡系統為例
    46
    6:00 AM 12:00 PM 06:00 PM 00:00 AM
    N
    N+1k
    N+2k
    N+3k
    N+4k
    早上高峰負載測試 (Load Testing)
    - 逐漸增加吞吐量或 VU
    - 並在一段時間內保持該平均負載
    目的 : 測試系統在預期負載下的性能
    Credit to : https://k6.io/docs/test-types/
    

    View Slide

41. 測試場景 : 以打卡系統為例
    47
    6:00 AM 12:00 PM 06:00 PM 00:00 AM
    N
    N+1k
    N+2k
    N+3k
    N+4k
    下班高峰尖峰測試 (Spike Testing)
    - 模擬突然和非常高的負載
    - 缺乏穩定（滿載）持續時間或通常很短暫
    目的 : 確定系統的行為方式以及它是否能夠承受突然的負載衝擊
    Credit to : https://k6.io/docs/test-types/
    

    View Slide

42. 測試場景 : 以打卡系統為例
    48
    6:00 AM 12:00 PM 06:00 PM 00:00 AM
    N
    N+1k
    N+2k
    N+3k
    N+4k
    低流量穩定性測試 (Soak Testing)
    - 系統在較長時間內效能下降和資源消耗。
    - 系統在較長時間內的可用性和穩定性
    目的 : 長時間使用後的穩定性和可靠性，機器使用狀況
    Credit to : https://k6.io/docs/test-types/
    

    View Slide

43. 測試場景 : 以打卡系統為例
    49
    6:00 AM 12:00 PM 06:00 PM 00:00 AM
    N
    N+1k
    N+2k
    N+3k
    N+4k
    極限測試 (Breakpoint Testing)
    - 需要知道系統的負載是否預計會持續成長
    - 對程式碼庫或基礎設施進行重大更改之後
    目的 : 找到系統限制 (暴力解)
    Credit to : https://k6.io/docs/test-types/
    

    View Slide

44. Finding Peak Load & Baseline
    50
    Throughput
    Failures / Errors
    Users Users
    Safe Peak Unstable
    SLOs
    

    View Slide

45. 壓力測試工具選擇
    51
    關鍵因素 目的 說明 Note
    測試需求 定位問題 確定測試類型，網路/伺服器/應用程式/資料庫 單一使用者 vs. 多用戶並發
    用戶介面 操作便利性 選擇合適的使用者介面：圖形介面或命令列 圖形介面 vs. command
    script 操作便利性 腳本的易用性、方便性與參數化
    分析報告 性能診斷 性能指標與問題識別 簡單、易於理解的測試報告
    整合與支援 CI/CD 工具的整合能力和社區、官方支持
    成本 管理預算 考慮工具的購買成本和長期維護費用 免費開源 vs. 付費商業
    Performance 資源優化 對硬體和系統資源的需求
    Scalability 適應性 是否支援大規模使用者模擬
    系統架構 適應性 是否適合既有的系統架構 單體 vs. SOA vs. 微服務
    團隊 適應性 是否適合團隊的技能水平和偏好
    學習資源 知識傳遞 文件和學習資源
    

    View Slide

46. 壓力測試工具選擇
    52
    Azure Load Testing
    Grafana Labs
    

    View Slide

47. 壓力測試工具選擇 : k6
    53
    • Since 2016 18.5 starts
    • CNCF Project
    • Grafana lab
    Load Impact
    • Go
    • Performance
    Engine
    • CLI & API
    • 開發者體驗++
    Developer
    • Reliability Testing tool
    • Load testing、E2E
    • Integration Testing
    • Chaos Testing、Functional Testing
    Testing tool
    

    View Slide

48. k6 : Programmable
    54
    Credit to : https://www.slideshare.net/twMVC/twmvc44-k6
    

    View Slide

49. k6 : Result
    55
    Credit to : https://www.slideshare.net/twMVC/twmvc44-k6
    

    View Slide

50. Azure Load Testing : Result
    56
    Azure Load Testing
    

    View Slide

51. Azure Load Testing : Result
    57
    

    View Slide

52. Azure Load Testing : 整合 CI/CD
    58
    

    View Slide

53. 59
    Takeaways
    

    View Slide

54. 60
    壓力測試大冒險：解鎖應用程式
    的隱藏性能之謎
    面臨的挑戰 Goals & SLO
    壓力測試 工具選擇
    

    View Slide

55. Reference link
    • 如何量測系統的容量？
    • 讓我們用 k6 來進行壓測吧
    • K6 Docs
    • Testing Guides
    • awesome-k6
    61
    

    View Slide

56. Any question ?
    THANK
    YOU Marcus 的學習筆記
    marcus tung
    { MWC。Everyone 。chatGPT }
    

    View Slide

57. 63
    Extra :
    

    View Slide

58. 64
    流量 10 倍，會發生什麼事 ?
    

    View Slide

59. 高併發
    • 目的
    • 消峰填谷
    • 策略
    • 快取
    • 限流
    • 服務降級
    • 非同步
    • 排隊
    65
    Credit to : https://help.aliyun.com/document_detail/102687.html
    

    View Slide

60. 快取
    66
    Credit to : https://blog.bytebytego.com/p/from-0-to-millions-a-guide-to-scaling-7b4?ref=dailydev
    

    View Slide

61. 服務降級
    67
    全部不能用 vs. 部分可以用
    Credit to : https://blog.hubspot.com/marketing/504-gateway-timeout
    

    View Slide

62. 限流
    • http status code : 429 Too Many Requests
    68
    Credit to : https://www.wallarm.com/what/rate-limiting
    

    View Slide