《大型網站伺服器容量規劃》——3.2 通過壓力測試規劃容量

本節書摘來自異步社群《大型網站伺服器容量規劃》一書中的第3章，第3.2節,作者： 鄭鋼 更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

為了獲得系統的容量，專業一點的公司都會讓運維人員搭建一套線下的測試環境，讓qa線上下測試，通過壓力測試并結合監控來找出系統的極限值。最常見的壓力測試工具有ab（apache bench）和jmeter，它們是apache項目提供的，可以在apache官網中找到，還有loadrunner也很不錯。

雖然壓力測試是以實際請求來度量容量，看似是最真實的，但這種做法其實并不準确，因為系統的實際壓力負載和業務對應的具體指令緊密相關，而壓力測試通常僅做一次，其結果僅與當時的業務代碼相比對，但凡有新代碼上線後，由于涉及代碼不同，其對應的指令通常也會不同，是以之前所做的壓力測試便被推翻了。

也許有讀者說，可以讓qa人員每次都在新代碼上線前都做回歸測試。其實這一點并不靠譜，這說明不了解qa的工作。壓力測試中要檢查（也稱回歸測試）的測試用例非常多，這需要qa人員極大的耐心，而且線下測試機往往用淘汰下的機器，其性能與線上伺服器的性能差别很大，這注定了測試結果的不準确性。

既然壓力測試也不完全靠譜，那應該怎麼做呢？有的公司是這樣做的，用真實流量導向待測試的伺服器，也就是用線上實際壓力去做壓力測試，觀察機器負載或日志，直到出錯為止。

如果叢集中原本有10台伺服器，先去掉其中的4台伺服器，隻讓剩下的6台伺服器提供服務，測試人員通過觀察機器壓力負載或日志中輸出的資訊等手段來判定服務的穩定性。如果服務正常的話，繼續從叢集中下掉一些伺服器，直到伺服器壓力越來越大，線上業務報錯為止。毋容置疑，這肯定是最真實的測試結果。當然這需要魄力，哈哈……反正我不敢，無論業務是多麼不重要，也不能犧牲使用者體驗來測試極限容量。