性能测试用到的主要术语

 

l 响应时间

对请求作出响应所需的时间。它是作为用户视角的软件性能的主要体现。

响应时间分为2部分：呈现时间、系统响应时间。呈现时间取决于数据在被客户端收到响应数据后呈现页面所消耗的时间；系统响应时间指应用系统从请求发出开始到客户端接收到数据所消耗的时间。一般主要关心【系统响应时间】。图略

注明：N1为客户端到web服务器请求的时间

     N2为web服务器到数据库服务器的请求时间

     N3为数据库服务器给web服务器的反馈时间

     N4为web服务器给客户端反馈的时间

    A1、A3为应用服务器延迟时间

    A2为数据库延迟时间

页面响应时间可以被分解为“网络传输时间”（N1+N2+N3+N4）和“应用延迟时间”（A1+A2+A3）,而“应用延迟时间”又可以分解为“数据库延迟时间”（A2）和“应用服务器延迟时间”（A1+A3）。

响应时间的长短没有绝对，国际上没有固定指标，因此响应时间的长度是个区间，比如，一个电子商务web，可能被用户接受的响应时间2/5/10；2秒最为被用户接受，数据响应最佳；

5秒用户可以接受，10秒可能是用户接受的底限，除非必须访问该网站，否则当页面还没有完全展示，用户可能就关闭了。当然，这个也不是必须的，比如对于晚上纳税系统来说，可能一次上传数据非常大，因此，每次响应时间可能会达到40分钟～2小时，这个用户可能也会接受，因为毕竟不是每天都会这样，可能每月只有一次。

因此，合理的响应时间取决于实际的用户需要，不要生搬硬套。

l 并发用户数

并发用户数：从业务角度看，同一个时间内，多少用户访问被测试系统（集合功能）；抛开业务角度看，同样是一定数量的并发用户数，如果用户数的操作方式不同（场景不同），服务器承受压力是完全不同的。

估算并发用户数的公式：

C=nL/T  （1）
C1=C+3√C （2）

公式1中,C是平均的并发用户数；n 是login session 的数量；L是login session的平均长度；T是考察的时间长度。如果一个典型OA应用，考试时间段长度应该为8小时工作时间。

公式2中，给出并发用户数峰值的计算方式，其中C1 指并发用户数的峰值。

实例：oa系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时使用该系统。更加公式1，2 可以得到：

C=400×4/8=200； C1=200+3×

√200

 =242

 

另一种方法估算：C=n/10   C1=r×C   r为2,3,4… 平均并发用户数为每天访问量的10%，峰值为平均值的r倍。

l 吞吐量

单位时间内系统处理客户请求的数量。一般用【请求数（点击数）/秒】或者【页面数/秒】来衡量。从业务角度来讲，吞吐量也可以用【访问人数/天】或者【处理的业务数/小时】等单位来衡量；从网络角度来说，吞吐量可以用【字节数/天】来衡量。

例如：对于一个web应用系统来说，从系统处理能力考虑，可以以【页面数/秒】作为吞吐量的标准；对一个银行的业务前台系统来说，可以以其处理的【业务数/小时】作为吞吐量的标准。

对于交互式应用，“并发用户数”、“响应时间”可以确定系统的性能规划；对于非交互式应用，用“吞吐量”来描述系统性能的期望可能更加合理。

吞吐量和并发用户数之间存在一定的联系。在没有遇到性能瓶颈的时候，吞吐量可以采用如下公式计算：_u

F=  

F——吞吐量

Nvu——VU（virtuae Use，虚拟用户）的个数

R——每个VU发出的请求（单击）数量

T——性能测试所用的时间。

l 性能计数器

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

资源利用率：系统中各种资源的使用状况。“资源的实际使用情况/总的资源可用量”形成资源利用率的数据，用以进行各种资源使用的比较。

同样条件下，某个资源A的使用率达到了接近100%的数值，而其他资源利用率都处于比较低的水平，则，资源A就可能是系统的一个性能瓶颈。

l 思考时间

也叫“休眠时间”，用户在操作期间，每个请求之间的间隔时间。为了较为真实模拟用户在实际操作中，发生的思考时间，请看公式：R=

从F=  和该公式进行简化可得：吞吐量与Nvu成正比，而与Ts成反比。

计算思考时间的一般步骤：

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

统计出系统平均的吞吐量；

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

根据公式：R=  计算出思考时间。