性能测试术语

软件性能的几个主要术语

　　1、响应时间：对请求作出响应所需要的时间。在所有加载的用户稳定运行后，目标系统平均

     完成客户端用户请求的一个交易的总时长

　　

　　网络传输时间：N1+N2+N3+N4

　　应用服务器处理时间：A1+A3

　　数据库服务器处理时间：A2

　　响应时间=N1+A1+N2+A2+N3+A3+N4

　　2、并发用户数的计算公式

　　系统用户数：系统额定的用户数量，如一个OA系统，可能使用该系统的用户总数是2000个，那么这个数量，就是系统用户数

　　同时在线用户数：在一定的时间范围内，最大的同时在线用户数量

　　平均并发用户数的计算：

　　C=nL / T

　　其中C是平均的并发用户数，n是平均每天访问用户数，L是一天内用户从登录到退出的平均时间（操作平均时间），T是考察时间长度（一天内多长时间有用户使用系统）

　　并发用户数峰值计算：

　　C^ 约等于 C + 3*根号C

　　其中C^是并发用户峰值，C是平均并发用户数，该公式遵循泊松分布理论

　　3、吞吐量的计算公式

    吞吐量(TPS)即在所有加载的用户稳定运行后，目标系统在单位时间内完成被请求的交易的数量。在使用测试工具模拟业务请求压力时，吞吐量TPS是指所有被加载的虚拟用户在运行一段时间后稳定获得的每秒交易数。

　　指单位时间内系统处理用户的请求数

　　从业务角度看，吞吐量可以用：请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量

　　从网络角度看，吞吐量可以用：字节/秒 来衡量

　　对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，他能够说明系统的负载能力

　　以不同方式表达的吞吐量可以说明不同层次的问题，例如，以字节数/秒方式可以表示数要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈；已请求数/秒的方式表示主要是受应用服务器和应用代码的制约体现出的瓶颈。

　　当没有遇到性能瓶颈的时候，吞吐量与虚拟用户数之间存在一定的联系，可以采用以下公式计算：F=VU * R / T

　　其中F为吞吐量，VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间

　　4、性能计数器

　　是描述服务器或操作系统性能的一些数据指标，如使用内存数、进程时间，在性能测试中发挥着“监控和分析”的作用，尤其是在分析统统可扩展性、进行新能瓶颈定位时有着非常关键的作用。

　　资源利用率：指系统各种资源的使用情况，如cpu占用率为68%，内存占用率为55%，一般使用“资源实际使用/总的资源可用量”形成资源利用率。

　　5、思考时间的计算公式

　　Think Time，从业务角度来看，这个时间指用户进行操作时每个请求之间的时间间隔，而在做新能测试时，为了模拟这样的时间间隔，引入了思考时间这个概念，来更加真实的模拟用户的操作。

　　在吞吐量这个公式中F=VU * R / T说明吞吐量F是VU数量、每个用户发出的请求数R和时间T的函数，而其中的R又可以用时间T和用户思考时间TS来计算：R = T / TS

　　下面给出一个计算思考时间的一般步骤：

　　A、 首先计算出系统的并发用户数

　　C=nL / T F=R×C

　　B、 统计出系统平均的吞吐量

　　F=VU * R / T R×C = VU * R / T

　　C、 统计出平均每个用户发出的请求数量

　　R=u*C*T/VU

　　D、根据公式计算出思考时间

　　TS=T/R

   

   

   无论有无思考时间（T_think），测试所得的TPS值和并发虚拟用户数

    (U_concurrent)、Loadrunner读取的交易响应时间（T_response）之间有以下关

    系（稳定运行情况下）：TPS=U_concurrent / (T_response+T_think)。

 

 

 

示例1：

计算机系统的总体性能标准是吞吐量和响应时间。

 

吞吐量是对单位时间内完成的工作量的量度。示例包括：

    每分钟的数据库事务

    每秒传送的文件千字节数

    每秒读或写的文件千字节数

    每分钟的 Web 服务器命中数

 

响应时间是提交请求和返回该请求的响应之间使用的时间。示例包括：

    数据库查询花费的时间

    将字符回显到终端上花费的时间

    访问 Web 页面花费的时间

 

这些度量之间的关系很复杂。有时可能以响应时间为代价而得到较高的吞吐量，而有时候又要以吞吐量为代价得到较好的响应时间。在其他情况下，一个单独的更改可能对两者都有提高。可接受的性能基于合理的吞吐量与合理的响应时间相结合。

 

通常，平均响应时间越短，系统吞吐量越大；平均响应时间越长，系统吞吐量越小。但是，系统吞吐量越大，未必平均响应时间越短。因为在某些情况（例如，不增加任何硬件配置）吞吐量的增大，有时会把平均响应时间作为牺牲，来换取一段时间处理更多的请求。

 

举个例子：一个理发店，只有一个理发师、一把理发椅子、一张方便客人等待的长凳。理发师一次只能处理一个客户，其他等待的用户显得很不耐烦，外面打算进来理发的人也放弃了在这家店理发的打算……

 

有一天，理发师有钱了，他多买了2把理发椅子。这样他可以同时给3个人理发：当其中一个人理到一定阶段需要调整或定型的时候，他就转向另外一个客户为其服务，依次类推。这样，他发现一天内他可以理的人数比以前增多了，但是还会有一些后来的客户抱怨等待时间太长。（吞吐量大了，但平均响应时间却长了）

 

后来，理发师招了2名学徒帮他一起干活。他发现这样一来每天的理发效率增加了将近2倍，而且客户的等待时间也明显减少。但是成本增多了，理发用具、洗发水、发工资，这让他觉得开个理发店也要精打细算。（平均响应时间短了，吞吐量也大了，但是成本却高了）

 

 

示例2： 

 

我们可以利用“门”的概念来理解这里面的偏差！

　　首先，我们假设如下的情况：

　　共有5个人；

　　有1扇门；

　　一个人通过这扇门需要花费1秒的时间；

　　此时，这扇门的吞吐量为1人/秒。5个人通过这扇门的平均响应时间为（1+2+3+4+5）/5=3秒。

　　如何才能提高人的通过效率呢？即，如何才能提高门的吞吐量呢？

　　有两种方法：

　　（1）减小通过门的时间；

　　（2）增加门的数量

　　例如，

　　（1）将一个人通过门的时间减小为0.5秒，门的吞吐量变成了2人/秒；

　　（2）增加一个门，门的吞吐量也变成了2人/秒

　　结果是：

　　（1）5个人通过改善通过时间的门的平均响应时间为（0.5+1+1.5+2+2.5）/5＝1.5秒；

　　（2）5个人通过两扇门的平均响应时间为（1+1+2+2+3）/5＝1.8秒

　　此时，你可以发现，软件开发员改进软件处理并发交易请求的方法有两个，第一种是提高单个请求的处理速率，第二种是增加处理请求的线程的数量；或者是两种方法的组合。但是，不同方法的使用并不代表吞吐量得到了提高，而同时软件典型交易的平均响应时间也获得了相同值的改善。

　　因此，在性能测试以吞吐量为检测指标的时候，不光要评估吞吐量是否符合了性能指标的要求，同时也必须考虑响应时间是否符合性能指标的要求。

　　假设，在测试前，规定了吞吐量为大于25笔交易/秒，平均响应时间为小于5秒，在测试后，若实际吞吐量等于27笔交易/秒，不能仅凭这个27笔交易/秒就确定该软件的性能符合要求了，还要看平均响应时间是否符合要求。这时的平均响应时间可能大于5秒。

　　而如果测试前，规定了在线人数为10000，平均响应时间为小于5秒，在测试后，仅凭实际平均响应时间等于4秒就可以判断该软件的性能符合要求。