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

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

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

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

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

Transcript

1. Marcus @ MWC 2023 壓力測試大冒險：解鎖應用程式 的隱藏性能之謎
2. 2 I’m ▸ 後端打雜工 ▸ #挑戰自我 #分享 #可觀測性 分享經驗 - COSCUP、MOPCON、DevopsDays - .NET Conf、Will 保哥線上技術分享 - 微軟活動 : 打造化繁為簡的雲原生平台 Hello! m@rcus 學習筆記 Marcus
3. 本次分享旨在與聽眾分享本人過往對於壓力測試議題的 個人觀點，本場不會談論任何技術細節，期待看到大量 技術、工具實務細節的朋友們，可能會大失所望。為不 耽誤您的青春，請趁其他教室關門前前往。 3 WARNING #新人（Newcomer） #開發者（Developers） #維運者（Operators）
4. 4 Agenda 1 Performance Testing 工具選擇 Takeaway 4 3 2 傳統監控工具的挑戰 Credit to : https://www.behance.net/diegocarbonell
5. 6 系統上線後，然後呢 ?
6. 上線後的挑戰 : 維運 7 Credit to : https://marcus116.blogspot.com/2020/03/tgonext-monolith-soa-microservices-system-architecture-evolution.html 複雜應用程式的挑戰 可視化的挑戰 大規模用戶負載的挑戰 Monitor Dashboard High concurrency
7. 8 流量 10 倍，會發生什麼事 ? Credit to https://kang0729.pixnet.net/blog/post/114597509
8. 大規模用戶負載的挑戰 9 Credit to : https://marcus116.blogspot.com/2020/03/tgonext-monolith-soa-microservices-system-architecture-evolution.html
9. 大規模用戶負載的挑戰 10 Credit to : https://marcus116.blogspot.com/2020/03/tgonext-monolith-soa-microservices-system-architecture-evolution.html
10. 大規模用戶負載的挑戰 11 Credit to : https://marcus116.blogspot.com/2020/03/tgonext-monolith-soa-microservices-system-architecture-evolution.html
11. 12 流量 10 倍，會發生什麼事 ? RD 會受傷 Credit to : https://game.udn.com/game/story/10453/3232490
12. 13 #大家的期待 Credit to : https://memes.tw/maker/template/39894
13. 14 What can we do ? 反思 : 系統應具備什麼樣的特性
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
15. 17 Make it work Make it right Make it fast - [質] 系統活著 - [質] 功能正常 - [量] 性能佳 (Performance)
16. 18 Performance 關於性能
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/
18. 20 What makes me recognize that I have a performance problem ? 反思 : 如何知道應用程式有性能議題
19. Application Slow : Single Task 21 Credit to : https://www.youtube.com/watch?app=desktop&v=f5VgIRThhkA
20. Application Slow : System slow 22 Credit to : https://www.youtube.com/watch?app=desktop&v=f5VgIRThhkA
21. Cloud : Scaling strategy 23 Credit to : https://www.binadox.com/blog/scalability-in-cloud-computing/
22. Develop : Commit Code 24 Credit to : https://twitter.com/8Zmsz/status/1399706303233019905
23. Architecture : 系統架構上的瓶頸 25 Distributed systems Credit to : https://read01.com/GPjeDDG.html
24. 目的 : 了解未知及帶來的風險 26 Credit to : https://engoo.com.tw/blog/%E4%B8%BB%E9%A1%8C%E9%A1%9E/know-known-unknow-unknown/
25. 27 Performance Testing 解開應用程式性能謎題
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
27. Testing Types and Strategies • 效能測試！= 壓力測試 • 非功能性需求 (Non-function required) • less traffic ≠ no performance problems • troubleshooting and debugging • 不同目標跟方式 29
28. 30 Testing Types and Strategies Spike : 驗證系統在活動突然、短暫和大量增加的情況下的行為 Smoke : 驗證腳本是否有效以及系統在最小負載下是否能夠充分執行 Average Load : 評估系統在預期正常條件下的效能 Stress : 評估當負載超過預期平均值時系統在其極限下的表現 Soak : 評估系統在較長時間內的可靠性和性能 Breakpoint : 逐漸增加負載，以確定系統的容量限制 Credit to : Load test types
29. 33 How do we begin ? 如何開始
30. 起手式 : Google Performance Tools 35
31. Performance Tools 36
32. 37 Yes, but not 可以說中文嗎 ?
33. ”專案開始之初，首重看見全貌” 38 - Ruddy Lee 老師
34. 測試計畫 : Testing Plan 39 Business Needs Stakeholder Requirements Test Scenario Execution (Test case) Result & Reporting
35. Business Needs : Defining Goals • Why : 為什麼需要測試 • ex : 了解系統目前狀況 • Define goals and required • ex : 順利度過雙11 • ex : 提升應用程式性能 20% • 結果是否符合預期 • 監控與追蹤成效 • 量化數據 & Test Report 41 Credit to : 我是誰 我在哪 我要去哪裡
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/
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/
38. 設計壓力測試場景 • 為了在過程中獲得 有意義的數據，制定清晰的測試場景 • 場景設計 : 定義你想要測試的情境，並設置相關環境。 • 合適的測試 : 定義應用程式的合理負載，以使其能夠應對不同情況。 • 準備測試數據 : 製作測試用的基礎數據，以生成更加真實的測試場景 44
39. 測試場景 : 以打卡系統為例 45 6:00 AM 12:00 PM 06:00 PM 00:00 AM N N+1k N+2k N+3k N+4k Insight ?
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/
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/
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/
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/
44. Finding Peak Load & Baseline 50 Throughput Failures / Errors Users Users Safe Peak Unstable SLOs
45. 壓力測試工具選擇 51 關鍵因素 目的 說明 Note 測試需求 定位問題 確定測試類型，網路/伺服器/應用程式/資料庫 單一使用者 vs. 多用戶並發 用戶介面 操作便利性 選擇合適的使用者介面：圖形介面或命令列 圖形介面 vs. command script 操作便利性 腳本的易用性、方便性與參數化 分析報告 性能診斷 性能指標與問題識別 簡單、易於理解的測試報告 整合與支援 CI/CD 工具的整合能力和社區、官方支持 成本 管理預算 考慮工具的購買成本和長期維護費用 免費開源 vs. 付費商業 Performance 資源優化 對硬體和系統資源的需求 Scalability 適應性 是否支援大規模使用者模擬 系統架構 適應性 是否適合既有的系統架構 單體 vs. SOA vs. 微服務 團隊 適應性 是否適合團隊的技能水平和偏好 學習資源 知識傳遞 文件和學習資源
46. 壓力測試工具選擇 52 Azure Load Testing Grafana Labs
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
48. k6 : Programmable 54 Credit to : https://www.slideshare.net/twMVC/twmvc44-k6
49. k6 : Result 55 Credit to : https://www.slideshare.net/twMVC/twmvc44-k6
50. Azure Load Testing : Result 56 Azure Load Testing
51. Azure Load Testing : Result 57
52. Azure Load Testing : 整合 CI/CD 58
53. 59 Takeaways
54. 60 壓力測試大冒險：解鎖應用程式 的隱藏性能之謎 面臨的挑戰 Goals & SLO 壓力測試 工具選擇
55. Reference link • 如何量測系統的容量？ • 讓我們用 k6 來進行壓測吧 • K6 Docs • Testing Guides • awesome-k6 61
56. Any question ? THANK YOU Marcus 的學習筆記 marcus tung { MWC。Everyone 。chatGPT }
57. 63 Extra :
58. 64 流量 10 倍，會發生什麼事 ?
59. 高併發 • 目的 • 消峰填谷 • 策略 • 快取 • 限流 • 服務降級 • 非同步 • 排隊 65 Credit to : https://help.aliyun.com/document_detail/102687.html
60. 快取 66 Credit to : https://blog.bytebytego.com/p/from-0-to-millions-a-guide-to-scaling-7b4?ref=dailydev
61. 服務降級 67 全部不能用 vs. 部分可以用 Credit to : https://blog.hubspot.com/marketing/504-gateway-timeout
62. 限流 • http status code : 429 Too Many Requests 68 Credit to : https://www.wallarm.com/what/rate-limiting