日活上百萬時，騰訊產品如何提前規避服務器宕機風險？

眾所周知，優異的應用性能是良好用戶體驗的堅實基礎，而服務器響應緩慢、卡頓、崩潰的產品，即便設計再精美也無法留住用戶的心。
2017年2月28日，百度就和用戶們開了一個不大不小的玩笑，從當天的20點54分到21點24分左右，百度搜索整整宕機了30分鐘，眾多網友戲言那30分鐘成為了百度最有存在感的30分鐘，但是從后來百度的公關文章中，可以看到其提到了“錯過了大家上億次的搜索請求”，從這個體量來看，這無論如何都是一次很大的影響了。 無獨有偶，今日頭條也在今年的1月出現了宕機現象，系統超過30分鐘未響應，頭條號的編輯后臺也無法進入，這些現象，均給用戶帶來了很大的困擾，而且用戶體量越大，影響的波及面就越廣，不僅影響用戶口碑，也影響產品收入。
   
如果把產品的月收入平攤到每一分鐘的話，大家可以通過30分鐘，60分鐘，乃至12小時，24小時的停服時間計算具體的損失金額，還要加上因此產生的用戶流失以及品牌口碑影響。
某國外知名游戲在上線之初沖擊到iOS免費榜第二名的時候，因為沒有做好應對大量玩家涌入的準備，服務器卡死、宕機，閃退讓玩家失望選擇離開，下載排名一度下降到475，通過兩個月的服務器優化才挽回局面。
這樣的例子有很多，隨著重度游戲，重度產品越來越多，產品越來越重視服務器性能的優化。本文將結合騰訊WeTest團隊為騰訊游戲及產品進行服務器壓測的經驗，分享一些方法和思路。

服務器性能核心指標有哪些

關于服務器壓測，有很多指標。為了讓大家更容易理解，舉個生活中的例子：
你中午去“海底撈”吃飯。
我們可以把“海底撈”這個飯店看成一個被測系統。
你去吃飯，就是對這個被測系統發起請求，對這個系統造成了一定的負載。你帶去的人越多，那么這個餐館就越繁忙，可以說餐館承受的負載就越大。
你開始點菜。這個時候你隔壁桌的人也開始點菜。那么你們兩個對這個系統產生了并發的請求。同時，其他桌有的在吃菜，有的在等菜，這些都是并發進行的事務。一個完整的吃飯事務可以定義成包括：點菜，下單，上菜，買單四個步驟。對于一個C/S的系統來說，可以對應于：建立連接，發送請求，接受應答，斷開連接。
影響一個餐館生意好壞的一個重要原因是上菜速度。上菜速度體現在兩個方面：
1.一個顧客請求的處理耗時，從下單到上菜中間等待的時間，我們稱之為響應時間。
2.這個餐館同時為多名顧客上菜的頻率，我們稱之為吞吐量。
來多少顧客，這是飯店自己無法控制的，但是飯店的上菜速度、餐位多少都會制約客流量。一定有一個峰值客流量，當來的客人超過了這個峰值，那么這些客人就會等位，或者是上菜速度超慢讓客人無法容忍。容量測試就是通過工具模擬足夠多的顧客來吃飯的事務，希望找到這樣一個客流量對飯店產生一定的負載，這個時候飯店既能接待最多的客戶同時也能保證最短的等待時間。更多的，還可以對這個酒樓人員配置和餐位設置等進行調優，以期達到一個最理想的資源利用率和效率。
客流量跟進來的客人多少有關，也跟餐館的接待能力有關。單方面增加來就餐的顧客，遭到投訴的可能性就越大，上錯菜的可能性也越大。
性能指標有很多，不可能全都看，那么有哪些核心的指標呢？
1、90%響應時間
是指所有用戶的響應時間由小到大進行排序，第90%的響應時間，是用來評估系統容量的重要指標之一。
2、TPS性能，關注服務器的服務能力。
每秒系統處理事務（通過、失敗以及停止）的數量。通過它可以確定系統在任何給定時刻的時間事務負載。
3、支持的最大在線人數。
指同時登錄站點的最大人數或者服務器同時接收下載的最大數量。

原文轉自：http://www.kjueaiud.com/ceshi/news/itdongtai/2017/0515/208439.html