壓測其實并非上線之前才進行，而是在開發之初就開始準備了。一般情況下在開發之前設計之時就應該明白哪些接口會面臨高并發壓力，所以在開發時就要按照能夠承受高并發的標準進行開發，比如盡量減少數據庫操作、采用連接池、邏輯盡量簡單等等。如果邏輯確實復雜，就要采用異步處理來解決。 **壓測的目的** 搞懂為什么要壓測，這樣在壓測的時候才不會事倍功半，畢竟壓測一次的成本還是蠻高的。壓測其實有兩個目的，一是測試應用在高并發情況下是否會報錯，進程是否會掛掉；二是測試應用的抗壓能力，預估應用的承載能力，為運維同學提供擴容的依據。 第一點很好理解，做好這一點就可以保證上線之后不出問題了。解釋下第二點，我們都知道就是架構設計的再優秀，代碼寫的再好，應對高并發單實例始終是有限的。所以通常是在滿足第一點的前提下，再根據可能到來的高并發壓力來計算需要多少實例來承載，而這就需要我們壓出極限。 **第一次壓測** 接口開發完成之后就可以進行第一次壓測。這一次壓測可以簡單壓一下，在本機進行就可以。壓測的目的是檢查代碼在高并發下是否會報錯。另外，編譯型語言要觀察是否存在內存泄漏，比如golang。 因為本機性能有限，一般來說按照100、200、300、500進程數進行壓測，壓到500如果沒有報錯就可以進行疲勞測試，觀察內存占用。 **第二次壓測** 一般來說是不可能在線上進行壓測的，所以一般都是在仿真環境。所以這就對仿真環境提出了更高的要求。 這一次壓測重點是壓極限。比如說我們目標并發數2000，那么就要從500-2000開始遞增的進行壓測。比如第一次壓500的時候就出現了一些報錯，這時候就是遇到了第一個瓶頸。當解決第一個之后再繼續壓500，確認解決了第一個瓶頸就可以繼續往上加，如此循環直到壓到目標并發數2000。 **常見的瓶頸** php-fpm進程數。一般php-fpm的進程數是dynamic模式，也就是說動態調整。這種模式下無法應對瞬時的高并發情況，因為他的進程數有個逐漸增加的過程。 負載均衡限額。比如阿里云的SLB最近就增加了配額限制，免費版的實例只有5000的最大連接數，3000的CPS和1000的QPS。 應用服務器、Redis、MySQL最大連接數、CPU和內存等等。這些都是比較嚴重的限制，所以一定要在壓測之前就搞清楚。 **如何來判斷遇到了什么瓶頸。** 503 -- 服務不可用，一般是負載均衡、nginx達到限制。 502 -- Bad Gateway，通常是應用進程掛掉了，或者進程不夠用處理不過來。 500 -- 應用故障，一般是應用拋出了異常沒有正常響應，比如達到Redis和MySQL的瓶頸。 **一個不算常見的瓶頸** Redis帶寬。阿里云的Redis是否帶寬限制的大概是200M+，如果數據量比較大，在高并發情況下很容易把帶寬打滿。目前的解決方案有兩個，一是在存入Redis之前進行數據壓縮，在讀取Redis之后再進行解壓。二是采用pb進行存儲，當然這兩種方案我都還沒有真正使用過，等我解決了這個瓶頸再來更新。 **一些壓測壓不出來的坑** 現在大多數正式的項目都是前后端分離的，所以上述說的其實都是壓后端接口，而有一種情況是壓根壓不出來的，那就是接口調用數。作為后端開發，一定要搞清楚承受沖擊的前端頁面在加載的過程中會調用幾個接口，調用幾次。如果不搞清楚這些，在真實環境中后端服務器就可能承受比前端服務器還高的壓力，從而影響之前針對壓測數據做出的評估。 **后序** 前面就已經提到過了，壓測一次的成本還是挺高的。在這個過程中還要需要各方配合，所以，最好是在壓測之前就做好詳細的計劃，這樣才能事半功倍。