日活上百万时，腾讯产品如何提前规避服务器宕机风险？

众所周知，优异的应用性能是良好用户体验的坚实基础，而服务器响应缓慢、卡顿、崩溃的产品，即便设计再精美也无法留住用户的心。
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.ltesting.net/ceshi/news/itdongtai/2017/0515/208439.html