一有“大瓜”出現，微博服務器便岌岌可危，到底是什么造成了微博崩潰，又該怎樣避免？

微博崩了的原因，很簡單，就是訪問請求超過了系統負載，在同一秒有巨量的用戶請求過來，而服務器來不及響應，被請求打爆了，因此崩潰了。修復的措施也很簡單，即通過增加服務器數量，讓服務器可以處理更多的用戶請求。那么如何衡量系統的性能呢？我們一般用這三個指標，響應時間、并發數、吞吐量來衡量系統性能。

響應時間，即請求發出到收到響應的時間，一般情況下，這個值都非常非常非常的小，微秒或毫秒級別，正常的網頁請求時間一般在2s以內，超過2s之后，用戶體驗就不佳了，超過20s，用戶無可忍耐，選擇離開，因此響應時間是非常重要的指標。并發數，指的是同一時間能處理的用戶請求數量。吞吐量，指的是單位時間能夠處理的請求數，體現的是系統整體處理能力，比如每秒請求數HPS、每秒事務數TPS、每秒查詢數QPS。

了解了系統性能衡量指標后，我們如何去找到這些指標的值呢？很簡單，就是性能測試，具體又可以分為負載測試、壓力測試、穩定性測試。負載測試指的是，對系統不斷的增加并發請求，增加系統的負載，直到系統的指標達到臨界值。壓力測試指的是，在超過系統安全負載的情況下，繼續增加壓力，直到系統崩潰，不能再處理任何請求，從而獲得系統的最大承受壓力值。穩定性測試，指的是在一定的壓力下，系統能夠穩定的運行時間，一般都是做7*24的穩定性測試。

一般來說，系統大部分時間都處于ab區間，當發生一些大事件時，系統的請求會增多，從ab區間變為bc區間，而爆炸性事件，則直接讓系統的請求巨量增加，從bc區間變為cd區間，從圖中我們也可以看到，在cd的時候，系統能處理的請求已經很少了，逐漸走向崩潰的邊緣，在d點徹底崩潰。而通過性能測試，我們能找到系統的b、c、d點，提前做好應對措施，比如返回上一級頁面，又或者是增加服務器數量等等。

那么如何進行性能測試呢？總的來說包含7部分，第一步前期準備、第二步環境搭建、第三步開發測試腳本、第四步準備測試數據、第五步執行測試、第六步分析結果與調優、第七步則是反饋跟蹤。在第一步前期準備中，我們主要是了解系統、分析需求、建立模型，在了解系統時主要關注系統的架構、開發語言、部署架構、操作系統數據庫中間件參數；在分析需求時關注即是否有預期承載值，測試目標是針對哪些核心流程、處理多少請求、占用資源要求、響應時間要求；在建立模型時，主要關注數據來源于數據庫日志或監控系統、系統負載吞吐量、系統壓力高峰時期分布情況。在第二步搭建環境，主要是準備服務器環境、測試機環境，測試機用于模擬用戶請求，服務器環境用戶模擬業務環境。在第三步開發測試腳本，主要是選擇對應的測試工具（如LoadRunner或Jmeter），使用腳本模擬用戶輸入、增加檢查點、增加數據收集與驗證。第四步則基于第三步的情況進行數據生成。第五步則開始執行測試，不斷施加壓力，監控業務系統的操作系統、網絡、數據庫各個層面的指標，比如CPU內存磁盤情況、網絡發送接收包數量等。第六步與第七步，則根據測試結果進行分析，不斷調整、測試、分析、反饋，直到拿到最終結果。

性能測試是最好的手段之一，通過測試找出系統瓶頸，提前優化，避免系統宕機、不可用事件又雙叒叕的發生。