但是，如果系統上線后，重大故障頻發，頻遭用戶投訴，怎么辦？前天是系統服務器 CPU 100% ，導致無法響應客戶請求；昨天是 數據庫 鎖表，大量 數據庫 連接阻塞，無法獲取需要的數據；今天是某個接口在高并發下出現異常……每天，我們在不停的滅火和陪笑，無止境的抱怨消耗著我們本不多的耐心。

靠人人跑，靠樹樹倒，只有自己拯救自己了，但要如何才能拯救我們自己于水火之中呢？最重要的技術手段，恐怕就要靠 系統壓力測試 了。

系統壓力測試 不應該僅僅是孤立的測試各個軟硬件的性能指標，而最重要的是要與軟件應用系統結合，盡可能的模擬真實的業務場景和數據，從而充分評估系統上線后可能發生的情況。也就是說，當業務量達到高峰時，各個服務器 CPU 指標大概是多少，內存指標大概是多少，當大量數據被查詢時，數據庫的響應時間是多久， IO 、網絡是否有問題？所有這些都應當事先被測量。

那么，如何去測量這些內同？主要就是以下方法：

1 、確定存量數據的規模（一般應至少制造出 3 － 5 年的存量數據，足夠的數據才能測出實際的效率和性能）；

2 、確定需要進行 系統壓力測試 的業務（一般是用戶使用最頻繁，或者業務操作最復雜的業務，比如各類的分析報表等）；

3 、確定操作用戶的的數量、各類操作用戶的比例；

4 、峰值業務量的要求（一般是 1 個小時內最多要處理的筆數）；

5 、對實時業務響應時間的要求（如在峰值情況下，一項操作的處理時間（如小于 20S ））；

當我們詳細測試了每一個主要性能，消除了其中隱含的性能故障；當我們設計了完整 系統壓力測試 方案，按照系統實際壓力進行測試，再用 2 倍的壓力、 3 倍的壓力測試……我們消除了一個又一個系統瓶頸，仔細檢查每一個細節，找不到錯誤的理由。現在，在系統性能方面，我們已經無法做的更好，因為我們已經做了所有應該做的事，和所有能做的事。

最后，時間會驗證我們的 系統壓力測試 結果。

歡迎您到我在 百洋軟件實驗室的正式博客 里留言討論

本文 做好系統的壓力測試 的方法轉載自百洋軟件實驗室

?

做好系統的壓力測試的方法