性能测试（一）

性能测试

前言

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

性能测试有几种？

1.负载均衡
2.压力测试
3.容量测试
4.稳定测试
5.并发测试
6.基准测试

性能指标有哪些

1.后台服务接口调用者关心：吞吐量，响应时间，等外部指标。
2.后台服务者关心：CPU，内存，负载，网络，IO，外部指标。

外部指标

1.吞吐量：每秒钟系统能够处理的请求数，任务数。
2.响应时间：服务处理一个请求或一个任务的耗时。
(智能提示对实时性要求比较高，一般在0.1s。导航返回结果的周期比较长，在2-5s)。
3.错误率：一批请求中结果出错的请求多占比例。

内部指标

1.CPU：后台服务的所有指令和数据处理都是由CPU负责，对CPU的利用率对服务的性能起着决定性的作用。

吞吐量

吞吐量的指标受到响应时间，服务器软硬件配置，网络状态正多方面影响。
1.1吞吐量越大，响应时间越长。
1.2服务器硬件配置越高，吞吐量越大。
1.3网络越差，吞吐量越小。
1.4在低吞吐量下的响应时间的均值分布比较稳定，不会产生太大的波动。
1.5在高吞吐量下，响应时间会随着吞吐量增长而增长，增长趋势可能是线性的，也可能接近指数的。当吞吐量接近系统的峰值时，响应时间会出现激增。
1.6错误率和服务的具体实现有关。通常情况下，由于网络超时等外部原因造成的错误比例不应超过5%，由于服务器本身导致的错误率不应超过1%。
一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。
2.1单个请求对cpu消耗越高，外部系统接口，IO影响速度越慢，系统吞吐能力越低。
2.2系统吞吐量几个重要参数：QPS(TPS)，并发数，响应时间
QTP(TPS):每秒钟请求/事物的数量
并发数：系统同时处理的请求/事物数
响应时间：一般取平均响应时间
QTP=并发数/平均响应时间
2.3一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。

响应时间（RT）

响应时间是指系统对请求作出响应的时间。
直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。
由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。
当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。
响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。
对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。
对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。

并发用户数

并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。
与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。
实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。
一网站系统为例，假设用户只有注册后才能使用，但注册用户并不是每时每刻都在使用该网站，因此具体一个时刻只有部分注册用户同时在线，在线用户就在浏览网站时会花很多时间阅读网站上的信息，因而具体一个时刻只有部分在线用户同时向系统发出请求。这样，对于网站系统我们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。
由于注册用户可能长时间不登陆网站，使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同事发请求用户数都可以作为性能指标。相比而言，以在线用户作为性能指标更直观些，而以同时发请求用户数作为性能指标更准确些。

QPS每秒查询率(Query Per Second)

每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。
对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。 （看来是类似于TPS，只是应用于特定场景的吞吐量）

CPU

1.us：用户态使用的cpu时间百分比
2.sy：系统态使用的cpu时间百分比
3.ni：用做nice加权的进程分配的用户态cpu时间百分比
4.id：空闲的cpu时间百分比
5.wa：cpu等待IO完成时间百分比
6.hi：硬中断消耗时间百分比
7.si：软中断消耗时间百分比

常见性能瓶颈

1.吞吐量到上限时系统负载未到阈值：一般是被测服务分配的系统资源过少导致的。测试过程中如果发现此类情况，可以从ulimit、系统开启的线程数、分配的内存等维度定位问题原因
2.CPU的us和sy不高，但wa很高：如果被测服务是磁盘IO密集型型服务，wa高属于正常现象。但如果不是此类服务，最可能导致wa高的原因有两个，一是服务对磁盘读写的业务逻辑有问题，读写频率过高，写入数据量过大，如不合理的数据载入策略、log过多等，都有可能导致这种问题。二是服务器内存不足，服务在swap分区不停的换入换出。
3.同一请求的响应时间忽大忽小：在正常吞吐量下发生此问题，可能的原因有两方面，一是服务对资源的加锁逻辑有问题，导致处理某些请求过程中花了大量的时间等待资源解锁；二是Linux本身分配给服务的资源有限，某些请求需要等待其他请求释放资源后才能继续执行。
4.内存持续上涨：在吞吐量固定的前提下，如果内存持续上涨，那么很有可能是被测服务存在明显的内存泄漏，需要使用valgrind等内存检查工具进行定位。