# 壓力測試大冒險：解鎖應用程式的隱藏性能之謎 / 董淳吉 (Marcus Tung)

{%hackmd @ModernWeb/SyA2U6SmT %}

> 共筆請從這開始

開場
過去大家比較多都在討論工具
但是比較少提到流程面、專案編排、Test plan
甚至怎麼符合 SLA 和 SLO 也是比較少被討論到的

## 傳統監控工具挑戰
維運是上線後的挑戰

- Monitor 複雜應用程式的挑戰.
服務愈切愈細, 微服務 ,分散式. 愈難監控.
- 可視化

- 大規模用戶挑戰
開始出現瓶頸 - 通常DB會是最早開始「紅」的，因為流量最後還是會回到DB

流量10倍, 會發生什麼事? RD受傷.
好了沒時間了, 你們都變成超級賽亞人吧, #大家的期待,
到底是系統壓力測試, 還是測試RD的抗壓性.

好的系統會有什麼特性?

RAS: Reliability, Availability and Serviceability
- 可靠性(**R**eliability)
- 平均無故障時間(MTBF) : e.g. 20天.
- 可用性(High **A**vailability)
- SLA : e.g. 99.9%
- 可維護性
- 系統修復或維護的簡單性和速度

可維護性為什麼重要，因為維持高可用成本很高

Make it work - [質]
Make it right - [質]
Make it Fast - [量] 性能佳(Performance)

fast大家比較不在意，靠user回報

about Performance
x: Concurrent users
y: Response time

(credit [k6.io](https://k6.io/docs/testing-guides/load-testing-websites/))

當user愈多時, response time 愈高.
上升到一定點時, 指數上升 (到極效了.)
bottleneck '通常'都是backend time

如何知道有效能議題
- single task
- system slow

我們怎麼判斷scaling，有依據嗎？
- 多少流量需要多少台機器？
> 你可以知道他可以承受的量是多少呢?
如果變3倍時, 你要怎麼調整.
> cloud 開到一定台數的時候, 財務會來關心你.

develop: commit code
'趁著雨勢大, 有不好的東西混進來了. '
如何知道有效能的問題? 要去思考一下.

跟SRE leader 聊天: deploy every 2 week , 對SRE來說就是災難的開始.
沒有人做效能測試就是去賭. 所以SRE會做監控.

系統架構上的瓶頸?
每個資深工程師都要知道..
面試時 : 10倍時會發生什麼事? 你知道嗎? 你要如何管理? 措施是什麼? 這是資深工程師必需要知道的. 為自己的application負責.

- 效能議題

架構：架構瓶頸

效能測試的目的：暸解未知及帶來的風險

KNOWN UNKNOWN：
UNKNOWN UNKNOWN：像是串接第三方金流，突然爆掉了，可是你不知道為什麼
效能測試，目的在於減少更多已知的未知，並挖出更多未知的未知。

壓力測試是效能測試的一種
非功能性需求 : 可能是資安相關功能/多語系
less traffic != no performance problems
> 只是還沒發現而已, 即使流量少也要做測試.

測試策略
- spike
- 短時間有大流量,
- smoke
- 驗證短時間、最小負載
- averageload
- 正常條件
- stress
- 超過預期平均值的極限表現
- soak
- 長時間可靠性
- breakpoint
- 直到爆掉, 測試臨界點

Stress Test: true/false (灣得過拓海/灣不過填海)

## Performance
<!-- 需要移動筆記 -->
## 工具選擇

Ruddy: 專案開始之初，要先看見全貌

選工具前需要測試計畫
- 確認商業需求
- 相關人員
- 收集需求
- 測試情境
- 執行
- 結果及報告

工具只是測試計劃的其中一個環節而已.

Bussiness Need -> Staksholder > Requirements > Test Scenario > Execution > Result&Report

### business need：定義目標
- Why為什麼需要測試
- Define goals and required
- 結果是否符合預期

SLA - 給客戶我們品質的KPI (我們對客戶的承諾, 對外)

SLO - 對內定義服務等級目標
SLI - 為了追蹤SLO會制定指標

舉例：
協議: 99% lateency < 300ms
SLO: 99% latency < 200ms
SLI: 1. 監控指標，例如出現99% latency > 200ms時
2. latency HTTP response 也回200.
3. 99% latency < 100ms
3個加起來, 都會滿足對外宣稱的 99% lateency < 300ms
meet SLA 是所有團隊要努力的結果, 要一起去meet 這個KPI

選擇要素
* 測試需求
* 分析報告
* 成本
* 團隊 - 適不適合團隊?
* 學習資源

* 用戶介面
* script
* 整合與支援
* 系統架構
* Scalability

## Takeaway

挑戰.
??
Goal
工具.

----
> 以下為聊天室

投影片有60多頁.

微軟 MVP 自稱小弟 QQ
他的簡報好勾錐
講師也很勾錐

攝影師又一柱擎天了 ＋1
正常會用閃光燈嗎
除了這場以外，我是有看過有用的啦
閃光燈是補光效果，會場暗暗的拍出來照片也會暗

不懂就問，K6全名是什麼？
=> [傳送門](https://k6.io)

樹懶變多了，但是一樣慢，好好笑喔
我隔壁的在度估XD
換我想要度估了

好奇問，這是已經上線後才有的資料，所以這樣的測試規劃會在上線後才發生嗎？
其實壓力測試上線前就要規劃了，測試期間是找出有沒有未達標的問題並提出修正，應該會有壓力測試清單，我覺得是這樣
感謝你

k6

怎麼感覺講測試的時候很容易看到Azure

會提供power point