我們在壓力測試要知道的事（ㄧ）提到關於物理限制的問題，在大多數時候我們的假設很可能是少考慮到了物理上的限制，然而除了物理限制外還有許多需要注意的地方。
商業考量
在我們要進行壓力測試的時候，必定會需要有「目標」而這個目標大多就是商業考量，也就是我們希望提供多大規模的服務。舉例來說，我們希望我們的系統在改版後可以提供 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）同時，我們還需要高規格的主機也可能源自於我們在軟體的設計上有許多不良的處理，造成卡頓、負載能力低下。
也因此，我們要了解自己的系統哪裡還能夠改進。就需要有足夠的軟體工程師素養，以這些知識為基礎搭配正確的估算系統的狀況，就可以知道需要改進的是硬體還是軟體會有更好的效益。
封面圖片使用 Unsplash 上 Norbert Kundrak 的作品，有想聽的主題可以透過匿名問卷告訴我，想了解專業的技術主題可以到弦而時習之找找靈感。