load test 碎碎念

又快到雙 11 了，今年的系統壓測跟往年不一樣，遇到了沒碰過的問題，還有改變了做法。

去年在和同仁準備雙 11 時，我推薦了使用 Artillery 來進行壓測，主要原因是看上它能夠部署在 AWS Lambda 執行，這樣就不用怕頂到機器的上限，可惜因為某些原因所以還是在一台機器上用 Artillery 測試。

而今年因為流量暴增許多，因此需要產生的流量比以往還要高出許多，最終頂到了機器的上限 —— 我把 port 消耗完了，解法很簡單: 直接使用 connection pool 就可以了，但代價是少測到 TCP 建立所產生的壓力。

在做法的部分，好像不管哪個產業，大家都想知道單一 pod 乘載能力， 從而計算出機器成本及效能最佳的配置。我覺得想法沒問題，只是時間不對，這件事平常就該進行，除了讓系統維持在最佳配置，也透過每日蒐集系統指標了解單一 pod 及系統乘載能力。(終於有空在今年透過 AI ，建立能夠長期追蹤的簡易 telemetry 了，之前推 Sentry 都一直碰到軟釘子 QQ)

坦白說，我是有點厭惡在這個時間點進行量 pod 和系統乘載能力的壓測，除了這是平常就該掌握的資訊之外，也覺得未免太流於形式了 (好像只是為了向上頭交差)

因此，今年我將主軸聚焦在回答問題上，並根據問題來設計實驗，總算沒有那種漫無目的感覺，而且有了答案之後，更清楚的知道某些過去 follow 的 SOP 早就不合時宜了。

就在我以為告一段落時，突然被主管告知，前同事留下來的一個很簡易的服務也要壓測，當初團隊都在燒其他事，沒空 review 他寫的 code，而且也認為服務很簡單應該沒問題，因此就讓他自行開發，現在來看真的是一大錯誤 (沒效率的邏輯、奇葩設計、log 就看的到的錯誤、鴕鳥心態 catch block 、抓不到異常的 alert ……etc)。

邊修邊測，終於讓這個簡易服務來到它應該有的乘載量，而且預估成本會更少，成功拆彈!