性能指标与常见术语

1、并发数

首先，理解三个用户数的概念：系统用户数、在线用户数、并发用户数

系统用户数就是一个系统中所有的注册用户数。eg. 当前微信中的所有注册用户数；在线用户数是当前登录系统的用户数，eg.当前登录微信的总用户数 （均为在线状态，不管该用户做什么操作）；并发用户数是指对Server产生压力的用户数，eg.当前微信所有登录用户中，正在进行操作的用户数（仅指对Server产生压力的操作）。我们测试时仅关注并发用户数，一般，需求采集人员会将线上的并发用户数根据日志或工具分析统计出。测试时，要以性能测试需求为准，此外，并发操作也包含多种情况 ，如所有用户同时进行购买或支付操作；或多个用户同时发出多个不同请求，如加入购物车、删除商品、增减数量、支付、退款等操作。

2、响应时间

先看一个请求从发出到用户看到结果的过程：用户发送一个请求后，通过网络传输、DNS解析等步骤到达Server端后，Server通过各种算法处理，将结果通过网络传输返回到Client，Client要经过解析渲染等步骤，最后才呈现给用户。

通过以上流程可知，响应时间的计算模式：响应时间=请求传输时间+Server处理时间+响应传输时间+前端解析渲染时间。

由此可见，在工作中，一方面响应时间要根据不同业务及用户的具体要求而定；另一方面分析结果时要注意当前的业务模型（如前端性能测试与服务器性能测试）

3、TPS

即Transaction Per Second，每秒通过事务数。TPS是直接反映系统性能的指标。TPS值与系统性能成正比。

环境不变的情况下，一个系统是有一个最大TPS值的。分析结果时，一般将TPS与平均事务响应时间作对比，以得出事务数量对响应时间的影响趋势。

4、吞吐量

即单位时间内系统能处理的请求数量，吞吐量也是可直接反映服务器所能承受的压力。

5、资源利用率

关于资源利用率初期了解以下几个重要指标即可：

6、CPU

对于CPU都不陌生，简言之，是用来处理＼判断事务的，CPU一般有系统CPU与用户CPU，前者是 处理系统占用的资源 ；而后者是处理应用程序占用的资源 。

7、网络

即网络传输的流量，测试过程中对网络的监控以，以分析是否存在瓶颈。

8、IO

即，Input/Output，输入/输出。关注与磁盘的交互频率等

9、内存

即数据存储区域。一般读数据时从内存中读取要比硬盘读取快很多 ，但需要关注的是内存溢出或内存泄漏问题。

10、队列

属于数据结构的概念了 ，是一种线性表，可以在队列前删除，在队尾处进行插入。测试过程中，如果发现队列越来越长，很可能会发生阻塞问题。

11、思考时间

简单理解 ，就是用户在几个操作时的间隔时间，是为了最大程度的模拟用户的实际操作；而有些系统会直接设定某些操作的间隔时间，如发布动态、申请提现等。尤其做压力测试时需要根据实际业务来设计场景。

1. 吞吐量

2. 并发用户数

3. 点击率

4. 资源利用率

5. TPS

6. 事务响应时间

软件性能测试的目的主要有以下三点：

Ø  评价系统当前性能，判断系统是否满足预期的性能需求。

Ø  寻找软件系统可能存在的性能问题，定位性能瓶颈并解决问题。

Ø  判定软件系统的性能表现，预见系统负载压力承受力，在应用部署之前，评估系统性能。

1.吞吐量（平均吞吐量）

吞吐量表示待测应用对业务的支持量，以TPS或QPS为单位，表示每秒钟能处理的请求数。

有一个很模糊的概念“并发数”，似乎和吞吐量有关：

比如经理说，这个系统要支持2000并发，那么这个要怎么理解，并发数和吞吐量是同一个东西吗。

不一定。

并发数可能是：

2.（总）并发用户数

同一时间在系统上的用户数量，这些用户可能分布在不同的功能模块或页面上。

也可能是：

3.（总）并发请求数

同一时间在系统上的用户同时向服务器做出的请求数量，这些请求也可能分布在不同的功能呢模块或页面上。

所以这个时候就问清楚经理，是 2000并发用户数，还是2000并发请求数。后续可以根据不同的回答来设计不同的测试场景。

再说一下为什么这里提到了测试场景。

因为在测试一个系统的性能或者说吞吐量时，离不开具体业务场景。在解释为什么之前，先看这个：

4.平均响应时间

一些请求从发起到收到服务端响应所需的时间的平均数。

说下为什么离不开具体业务场景，请看公式1：

一段时间内的平均吞吐量=这段时间内的总并发请求数/这段时间的平均响应时间

比如获取一个静态图片，响应时间就短，那么根据公式1，单位时间内的请求的平均响应时间越小，其平均吞吐量就越高。而如果是请求一个需要服务端做一定计算的资源，那么响应时间就长。自然按照公式1，就会发现吞吐量降低了。

也就是说响应时间和吞吐量成反比，因此讨论系统的性能时离不开响应时间，也就离不开具体的业务场景。

在实际测试工作中，我们会采用逐步加压的方式，一步一步提高虚拟的总并发用户数，并观察其响应时间变化，因为响应时间和吞吐量成反比，那么我们观察响应时间的时候其实也就是在观察吞吐量的变化。

压力较低时，吞吐量和虚拟的总并发用户数可能成正比。当用户数逐步增加上来之后，可能吞吐量的增加速度会逐渐下降。这是因为压力上升后，系统处理请求能力下降，平均响应时间加长。直至某一个点开始，吞吐量不再上升，反而下降。这就是系统处理能力的瓶颈了。

而在这个吞吐量上升的过程中，我们会观察到还有一个数字有可能上升，那就是：

5.错误率

一段时间内出错的请求在总请求数中的占比。

对于错误率的容忍程度，取决于不同的系统需求。那么一般错误又分情况：

5.1有返回值的错误，这里又要分是HTTP请求之类的错误，还是业务上的错误。这些可能出现错误的值需要在测试脚本里做校验，或者说断言。

5.2 没有返回值的错误，或者说就是超时。

有些请求会超时，那么不但会导致错误率的出现还会影响平均响应时间。

因为：平均响应时间=所有请求所需总时间/所有请求总数量

而个别超时的请求会严重增加请求所需总时间。因此，对于平均响应时间就会有更多细分，比如

6.90%平均响应时间

从计算平均响应时间的那些请求里去掉最慢的10%之后重新计算平均响应时间。

显然，使用90%平均响应时间，因为去掉了出错超时的那些请求，使得得到的数据更加接近真实值。

最后再介绍一个指标

7.平均传输带宽

这个指标用于计算服务端的数据传输量。单位是KIB/S，1k字节也就是1024字节。KIB/S就是每秒钟传输多少k字节。这个指标和我们上网的带宽是同一个指标。

了解了这些指标，那么就能大致上看懂一份性能测试报告了，应该也更能理解性能测试的设计方法了。当然还有一些服务端的资源使用指标等这次没讲。

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

通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。

压力测试是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。 

性能测试主要关注如下三个指标

吞吐量：每秒钟系统能够处理的请求数、任务数。

响应时间：服务处理一个请求或一个任务的耗时。

错误率：一批请求中结果出错的请求所占比例。

RT：响应时间

TPS：每秒完bai成事务数

CPU性能指标du：利用率、负载

Mem：内存性能指标，可用物理内存、虚拟内存使用率

Disk：磁盘性能指标，Disk Time、IO等待

NetWork：网络指标，带宽使用率、任务队列长度

TCP连接数，可以用netstat命令统计得到

中间件建立的线程池，监控线程状态

JVM性能指标，GC情况、Heap使用情况

CPU负载队列长度

服务器与中间件之间建立的连接数及连接状态

一般性能分析的过程

序号 步骤名称 说明

1 检查RT 客户端响应时间

2 检查TPS TPS大时RT小， 说明性能良好

吞吐量、并发用户数、点击率、资源利用率、TPS、事务响应时间

对于不同的项目来说，性能测试的侧重点是不一样的，对于app来说，性能测试更关注内存，CPU，耗电量，消耗的流量，流畅度，响应时间等

对于web项目来说，性能测试更关注吞吐量、点击量、点击率、响应时间、tps、并发用户数，内存，CPU

网络

即网络传输的流量，测试过程中对网络的监控以，以分析是否存在瓶颈。

IO

即，Input/Output，输入/输出。关注与磁盘的交互频率等

内存

即数据存储区域。一般读数据时从内存中读取要比硬盘读取快很多 ，但需要关注的是内存溢出或内存泄漏问题。

队列

属于数据结构的概念了 ，是一种线性表，可以在队列前删除，在队尾处进行插入。测试过程中，如果发现队列越来越长，很可能会发生阻塞问题。