壓力測試要知道的事(二)

2022/04/04閱讀時間約 1 分鐘
我們在壓力測試要知道的事(ㄧ)提到關於物理限制的問題,在大多數時候我們的假設很可能是少考慮到了物理上的限制,然而除了物理限制外還有許多需要注意的地方。

商業考量

在我們要進行壓力測試的時候,必定會需要有「目標」而這個目標大多就是商業考量,也就是我們希望提供多大規模的服務。

舉例來說,我們希望我們的系統在改版後可以提供 1 萬名會員使用,那麼我們後續用來評估的方式,就會以這個為基礎進行估算。也因此,在開始進行壓力測試之前,我們需要先設定一個「目標」這個目標可能是每秒要能處理幾筆訂單,或者每個月要能穩定提供多少使用者使用等等。

估算方式

既然有了目標,我們就可以根據預測的使用情況、過往的資料等等來進行一個簡單的估算,用來幫助我們了解壓力測試要能夠達到怎樣的水準,一般來說會以每秒能處理幾個請求(RPS)作為基準
想要抓出合理的壓力測試數值,我們除了要注意物理上的限制之外,也可以用比例的方式評估。假設我們認為大部分的使用者會集中在一天內的 20% 時間使用網站,同時每個月會有 1 萬個使用者,那麼每秒需要處理的單位可能會是 10,000÷(0.2×30×86400 ) 左右。
然而使用者也不可能是每天都使用網站,因此再繼續加入每天會有約 10% 的使用者會使用,那麼就可以繼續修正這個計算式為 (10,000×0.1)÷(0.2×30×86400 )
接下來我們要再繼續估算每個使用者的每天平均操作,假設從篩選商品到完成購物,大約是會有 6 個步驟,那麼每秒能處理 (10,000×0.1×6)÷(0.2×30×86400 )~= 0.01 個操作即可。
以上面的案例每個月要提供 1 萬名使用者(MAU,Monthly Active User)使用,每秒其實只需要達到能處理 1 個請求即可,是不是比想像中的還少?

正確的衡量

當初我了解到這樣的估算技巧後也是很驚訝的,因為我們很多時候可能都在高估我們的系統,也就是沒有正確的衡量我們應該分配的資源。
以我個人的經驗,大多數 5 美金一個月的虛擬主機,基本上就足以一個小專案成長到盈利,在現實中我們可能會因為新技術、錯誤的評估使用了複雜的部署方式(Ex. Kubernetes)同時,我們還需要高規格的主機也可能源自於我們在軟體的設計上有許多不良的處理,造成卡頓、負載能力低下。

也因此,我們要了解自己的系統哪裡還能夠改進。就需要有足夠的軟體工程師素養,以這些知識為基礎搭配正確的估算系統的狀況,就可以知道需要改進的是硬體還是軟體會有更好的效益。

封面圖片使用 UnsplashNorbert Kundrak 的作品,有想聽的主題可以透過匿名問卷告訴我,想了解專業的技術主題可以到弦而時習之找找靈感。
贊助支持創作者,成為他繼續創作的動力吧!
我是軟體開發的求道者蒼時弦也,主要使用猶如賢者之石一般的 Ruby 語言,期望能夠在軟體開發這條路上找出一個能讓每個人都享受撰寫程式樂趣的方法,並且讓世界上能有更多優秀的程式被設計出來。
軟體工程師逐漸變成一個熱門的職業,當我們進入這個職業之後應該要具備怎樣的技能才會在工作上更加順利呢?這系列的專欄會分享日常工作中的經驗以及一些案例分析,讓我們一起努力成為一位更優秀的軟體工程師吧!
如果要發表留言,請先登入註冊會員
享受沈浸的閱讀體驗
徜徉在不受干擾的簡約介面,瀏覽數百萬篇原創內容。
領取見面禮
只要設定追蹤作者,即可享有 48小時
Premium 閱讀權限