轉載：怎樣正確做 Web 應用的壓力測試？https://www.zhihu.com/question/19867883
作者：玩家翁偉
鏈接：https://www.zhihu.com/question/19867883/answer/391492300
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。

面試的時候，很多后端或者QA的候選人都會跟我講說有過壓力測試的經驗，但在我細問之后，極少有候選人能夠把壓力測試細節講清楚。這里整理一下我認為做壓力測試時需要注意的一些細節。環境首先環境是非常重要的，需要盡可能跟生產環境靠近。比方說，使用同樣的nginx版本，php的話需要啟用fpm，zend-optimizer等等，參數配置也最好跟生產環境保持一致。當然，php的版本更加需要保持一致，不能說線上是跑5.3，而測試環境卻是php 7；除非是要測試不同php版本的性能。網絡也需要注意，測試機跟服務器之間是什么網絡連接？100M還是千兆的網線？也同樣需要跟生產環境盡可能保持一致。我曾經看過有人直接在自己的筆記本上跑壓測的客戶端，然后筆記本使用的wifi；這直接就變成是在測試wifi的性能了。當然，也可以考慮直接在服務器本機上面跑壓測程序，這樣就可以規避掉網絡層的，更有針對的去看服務器應用的性能；但那就要注意壓測程序本身是否會占用過多的CPU、內存等資源而影響到服務器應用。在測試高并發的場景下，也要注意修改linux的open files limit:ulimit -n
命令可以顯示file descriptors的值，這值默認是1024；也就是說，最多只能開1024個并發連接；一般情況下夠用。如果需要測試C10K甚至更高的并發場景時，這個值就必須修改了；關于ulimit命令的詳細使用，可以參考這里工具最常見的web壓測工具是ab - apache benchmark；我偶爾會拿ab來做簡單的快速測試。但做嚴格的測試時，ab就會顯得非常不合適。首先，ab是單線程程序，只能利用單一CPU，在給性能好的服務器端應用做壓測時，往往跑ab的測試機負荷滿了；而服務器應用的性能還綽綽有余。這在測試默認啟用多核的go程序是非常常見的。建議至少使用techempower所用的wrk替代ab；wrk默認可以利用單一CPU的多個核。其次，ab僅能是對單一url進行壓測，而當我們僅僅只是反復測試單一URL時，出來的測試結果往往不能提現真實的壓力場景。比方說，應用程序反復查詢、返回同一個賬號的資料，跟隨機查詢、返回十萬個用戶是不一樣的；前者的返回結果很容易就被數據庫、應用給“緩存”掉。而對于被嚴重“緩存”的性能測試結果，并不能很好的反應真實場景下的性能表現。如果要模擬真實的壓測場景，我會推薦使用siege，siege的有多個參數方便模擬真實壓力場景：-f FILE, --file=FILE參數指定一個輸入文件，在文件中指定多個不同的url，然后對這多個url進行壓測。-i, --internet則是指定隨機發送輸入文件中的urlwrk也支持使用lua腳本去生成壓測的請求，siege上面能做的，wrk肯定也可以通過自己編寫腳本去實現。瓶頸我會認為，壓測的目的是在于找到系統的瓶頸，一定是要確定系統某個方面達到瓶頸了，壓力測試才算是基本完成。當我們說系統可以支撐某某壓力時，一定要同時能夠清楚的說出系統的瓶頸是在哪里；也就是說，當瓶頸得到改善的時候，系統的性能可以得到提高。對于web應用，系統的瓶頸往往會是數據庫；系統滿負荷運作的時候，數據庫的CPU或者是磁盤IO是否跑滿了？如果沒有，那么很可能是說明瓶頸是在別的地方；如果是在應用，那么應用服務器的CPU、內存、IO等等也應該有所體現。找到系統的瓶頸，是需要反復做不同測試、優化，然后分析出來的。對于一些性能有高要求的公司，比方說七牛云，據說他們只接受網絡IO這一瓶頸，壓測的時候，是一定要把千兆網卡跑滿，才算是性能達標；如果網卡沒跑滿，那就說明瓶頸是在別的地方，要去不斷優化，直到網卡的物理限制成為系統的瓶頸。延遲與吞吐延遲latency與吞吐thoughput，是兩個相關，但其實獨立的概念。最理想的系統是低延遲，高吞吐；但有時高延遲的系統，吞吐是可以超過低延遲的系統的。最后偶已經離開一線開發好幾年，上述都是根據我差不多5年前的記憶寫的，一定會有錯漏之處，還望讀者指正哈！

總結

以上是生活随笔為你收集整理的怎样正确做 Web 应用的压力测试？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。