一、性能指标

我们知道服务器，有 CPU、内存、IO、网络等一系列指标，除了这些系统级的，还有些针对各个语言自己的性能参数，而一个服务器的吞度量与请求对CPU的消耗、外部接口、IO等等紧密关联的 ,面对这么多繁杂的参数我们如何有效而快速的利用,如何评估这些性能参数信息? 下面我以游戏服务器来为例说一下我们主要关注点。

我们主要关注以下3个点:

并发数:并发请求数

响应时间:平均响应时间

TPS:每秒钟处理事务数量

TPS =并发数/响应时间

通过上面我们看到，TPS可是反映一个服务器的吞吐量的综合值，他是我们评估服务器性能的一个重要参考，通过tps，我们可以知道单台服务器的最大请求可以处理多少，pcu(同时在线人数)是多少 ，以及配合其他性能参数，我们还可以定位到服务器的性能瓶颈,所以我们预估服务器的性能的时候，TPS是一个关键的参考值。

二、上线前的测试流程

1、测试模型设计

这一部分，也可以叫测试目的的确定，不同测试目的，对测试模型的要求也不一致，测试目的的定位，也决定了每次测试的方案和偏重点会不一样，所以不能一概而全，要区别对待。

我们一般会有一些如下的区分：

服务器TPS测定，也是定位服务器的最大承载量，我们需要优先通过压力测试找到TPS的初始值，然后再进行稳定性测试和容灾测试，找到TPS的稳定值范围在哪里，最终修正TPS值。

性能瓶颈定位，通过压测和关键指标数据的收集，定位服务器性能瓶颈的区域。

关键接口指标，针对关键接口做一些指标收集。

2、压力测试

压力测试主要是测试服务器在极限情况下的承载是怎样的，以及能够达到怎样的极限值。做压力测试还需要针对性的编写一些压测机器人来帮忙我们发起密集的请求，以让服务器达到满荷的状态。

我们的压测主    要包含这几个方面：

1)、指令机器人

指令机器人是压测发起 主体，你可以把他看作为一个模拟的用户，模拟用户的指定行为，和收集一些关键数据。从功能方面来看，机器人主要功能，根据输入指令，发起特定请求(批量或者单个)，收集请求和回复数据。

由于每个游戏的业务类型不一样，协议也有自己的加解密方式，所以相对要复杂些，而且复用性也比较差。而web方面的指令机器人，简单易用，只要把关键的部分通过元数据来配置，基本可以做到一次编写，到处乱用的目的。

2)、指令的录入

指令一般都是client向服务器发起的request，每种应用不尽相同，可以自己编写指定格式，也可以在服务器或者客户端进行指令录入，因为游戏协议 的特殊性我们一般是做录入来处理，这个也可以根据自己需求来，主要是保证，指令能够让方便机器人读取就行。

3)、数据准备和指标的录入

游戏一般是有状态的情况，所以在除了指令录入还需要准备些初始化的数据，比如模拟帐号，一些道具的初始等等。机器人不但负责请求，还得有一定的数据收集功能，一般的数据包含如下，

request数量/秒，成功率多少，失败率多少,还有每个接口的请求次数，平均耗时等。在腾讯这边，有时候会需要这些数据上传到统计平台，来统计测试的统计图，做最终的压测指标。

这里给大家截图一个我们平常使用的输出模型:

这个图我么可以看到，总共请求了9960次，成功100%，870次请求／s,,请求间隔时间,11.450s，最快3.3ms,最慢871.6ms。

以上这几部主要做压测的基础功能，在测试的时候，我们需要把指令机器人跑起来，不断的加量，看服务器的运行状况，以此来评测服务器的tps。

3、稳定性测试

稳定性测试就是要测试服务器的稳定性，有时候服务器在功能测试的时候并不能测试到一些状况，比如长时间运行会有资源的没释放，导致的GC的问题，或者是DB快速增长后的访问变慢问题，这些就需要稳定性测试来发现问题。

我们一般在做出压力测试情况下，会计算出单台服务器的tps，然后以此tps压力下，让机器人测试19小时以上，期间会检测服务器相关的cpu，内存，网关流量；逻辑进程相关的，cpu，句柄，gc次数，线程数；缓存服务器的cpu，以及网络流量等。通过查看这些参数的运行曲线，会很容易发现一些常见的问题。关于这些参数的监控工具，常用的有很多，我就不一一推荐了。

4、容灾测试

容灾测试就是测试下服务器在出现意外的情况下，如何快速的修复服务或者保障服务器不宕机。

在腾讯合作的项目中，一般会有要求30分钟以内恢复，这个就需要上线前，做一些容灾演练，这个期间需要保证每个组件都能够足够健壮了，在集群内的单个组件发生状况了，守护程序能够主动发现并拉起或者报警，备用组件能够即时的跟进，保证不会因为某一个组件出现问题，而导致服务器长时间无法访问。

我们一般这么做，正在运行的服务器中，随机kill其中一个memcache主机，看守护程序是否可以快速拉起，会不会出现脏数据。或者在DB方面，kill其中一个主机，看是否实现数据分片后存储节点的冗余与互备，在出故障时，有效保障数据处理不间断

5.关键接口测试

每个系统都有一些关键接口，接口的关键与否和业务有很大关系。有时候我们需要拿到这些关键接口的指标评估，比如关键接口的评估标准，优化前后的数据对比和性能提升对比等。

关键接口测试要做到安全稳定，性能提升的前提要保证接口的安全和稳定。

以上这些是我们一般会用到的测试方式，几种测试方式可以组合为一种测试方案，流程也会不相同。当然了一般情况下，我们会把这些流程都走一遍，保证不遗漏，数据更全面。

三，上线服务器的数量的预估

评估上线服务器数量，我们需要一步步反推。比如，上线的某一段周期内，会有多少流量(用户)导入，单台服务器能够承受多少流量，有了这两个值，预估的服务器数量＝拿总流量／单台服务器承压流量。当然了，总会有些误差，我们一般还要多处20%的预留，预留你懂的，总有意外，出来了意外总不能去甩锅吧。

上面我们讲了2个关键指标，总流量，单台服务器承压流量。这里的流量需要和业务需求挂钩的，比如BS架构的互联网产品，PV(点击)是流量单位，而CS架构的游戏，则用户是流量单位。每种业务不同评判的标准不尽相同，需要根据自己的需求来。下面我以游戏为例来举栗。

前面的测试已经帮我们拿到重要数据了，TPS，那TPS如何来转换为用户呐？要想讲清这个，我们先回顾下TPS概念，TPS是每秒的事务数，在游戏里这里的单个事务是指一个用户所执行的一组指令所耗费的时间，是一组而不是一个，为何是一组，因为每个指令耗费的时间不尽相同，单个指令的TPS毫无疑义，一组才能代表一个用户的真正行为。此时TPS就可以间接转换为用户数了，但还要考虑一个比率问题，真实用户是无法达到机器人的水准的，也就是tps转换用户数要变大。比如压测出的机器人tps是1000，机器人执行一组指令需要160s,而真实用户执行需要1605s,此时的最终单台服务器承压用户数为1000*10=10000。

对于总流量，我们可以和运营人员沟通，这次导入的新用户指标是多少，再根据以往的经验或者公测数据，就能估算出预计的PCU(同时在线用户)和DAU是多少。有了PCU，总流量就知道是多少了，最终的服务器数量也可以预估出来了。

对于B/S架构的互联网产品，我只能浅略的讲下之前的经验了。之前做的时候，上线前能够向运营拿到的数据是推广量，一个PV(点击)算一个推广量单位。我们是这么处理的，按照用户的习惯，我们的产品一般会在10：00-14：00，16:00-22:00期间达到访问高峰，也就是10个小时，如果单台服务器的tps为10000，单台服务器的可以承受的日PV＝10000*10*1(相当于按最高TPS访问10个小时，不同的应用场景会有一些不同)，有了日PV，那么我们预估出服务器数量应该是:总推广量/单台服务器的日PV。

四、后续

以上就是一些对服务器上线前的一些测试流程，通过这些流程，我们就可以对服务器有一个大概的了解，比如 服务器瓶颈会在哪里 ，出现特殊情况，如何做预案等。

另外测试数据只能提供一个初始值，正在的上线的时候，会出现一些其他的状况，需要针对测试的数据进行修正，如果偏差比较大，要对不完善的方案进行改进。我们是不可能预估出真实的数据的，只能无限接近这个值。

还有一些其他的测试方案和流程我没有讲到，以后再表。测试流程的设定应该根据自身情况来，没必要每步必做，大公司有大公司的规范，小公司有小公司的流程，选择自己适合的最重要。