1.4 性能测试指标
1.响应时间（Response Time）
响应时间=用户响应时间+前端响应时间+网络响应时间+服务器端响应时间+数据库响应时间，是反映系统处理效率的指标之一。
响应时间是从开始到完成某项工作所需时间的度量。嵌入式产品，响应时间不包括人的反应时间，而对于其他产品，大多数都是人机交互的，响应时间体现在人的直观体验感受。在B/S系统中有一个著名的2/5/10原则，即网页在0-2秒内显示，所有用户可以接受；在2-5秒内显示，大部分用户可以接受；5-10秒内显示，只有少部分用户可以接受；10秒以上就几乎没有用户可以接受了。
另外合理的响应时间要与用户需求相结合，如在银行输入系统中，导入数据花费2个小时，那么输出响应能在20分钟内完成，性能就很不错了。
通过图3-6可以看出，响应时间=B1+W1+S1+W2+D+W3+S2+W4+B2，其中。
•W1、W2、W3、W4。网络响应时间。
•B1、B2。前端响应时间。
•S1、S2。服务器响应时间。
•D=数据库处理时间。
图3-6 响应时间
案例3-6：某网站的表单提交响应时间。
一个网站前端使用的是HTML5+CSS3+JavaScript+Ajax技术，服务器语言采用的是JSP+JavaBean技术，数据库采用的是Orcale。该网站某个表单提交的响应时间包括如下步骤。
（1）用户输入信息提交表单的时间。
（2）前端验证输入信息的时间。
（3）前端处理输入信息的时间。
（4）前端输入信息传输到Web Server的时间。
（5）jsp+javabean程序处理输入信息的时间。
（6）输入信息从Web Server到Oracle的传输时间。
（7）Oracle插入数据处理时间。
（8）Oracle将插入数据成功与否的信息传输到Web Server的时间。
（9）Web Server将插入数据成功与否的信息传输到前端的时间。
（10）前端插入数据成功与否的信息展示时间。
（11）用户接收到显示信息的时间。
2. 吞吐率（Throughput Rate）
吞吐率是单位时间内的吞吐量。吞吐量是服务器所能处理事务的能力。吞吐率的单位为字节数/秒、业务数/秒、点击数/秒、请求数/秒。随着负载的增加，吞吐率往往增长到一个峰值后，然后下降，队列变长。注意：在性能测试领域吞吐量是没有意义的，吞吐率才有意义。比如说某台服务器可以处理5T大小的数据，那么多的数据是1小时内处理完毕还是一天（24小时）处理完毕？如果是1小时内处理完毕，吞吐率为5T/h，性能是非常不错的；但是如果是24小时内处理完毕，吞吐率为5T÷24=208 G/h，性能就差很多。
为了让各位更好地理解吞吐率。以马路作为一个例子，见图3-7。
图3-7 马路的吞吐率
当马路上只有一辆车子运行，车子运行是非常畅通的，吞吐量也为1；随着汽车越来越多，单位时间内通过的车越来越多，也就是说这时候马路上车的吞吐量为n（n>1）；随着更多的车子加入，马路达到饱和，出现了堵车的情形。虽然想进入这条马路上的车和在这条马路上的车为k，但是马路上最多可以行使的车保持在m辆（n<m<k）。也就是说马路达到了拐点，最多处理能力为同时行驶m辆车。。
案例3-7：理发师模型
理发师模型是经典的解释吞吐率与响应时间的模型。比如有一家理发馆，里面有3名理发师，每个理发师水平相当，每给一位顾客理发需要10分钟的时间，如表3-1所示。
表3-1理发师模型
设置并发数 |
总响应时间 |
平均响应时间 |
实际并发数 |
1 |
10分钟×1=10分钟 |
10分钟/1=10分钟 |
1 |
2 |
10分钟×2=20分钟 |
20分钟/2=10分钟 |
2 |
3 |
10分钟×3=30分钟 |
30分钟/3=10分钟 |
3 |
4 |
20分钟×1+10分钟×3=50分钟 |
50分钟/4=12.5分钟 |
3 |
5 |
20分钟×2+10分钟×3=70分钟 |
70分钟/5=14分钟 |
3 |
6 |
20分钟×3+10分钟×3=90分钟 |
90分钟/6=15分钟 |
3 |
7 |
30分钟×1+20分钟×3+10分钟×3=120分钟 |
120分钟/7=17.1分钟 |
3 |
8 |
30分钟×2+20分钟×3+10分钟×3=150分钟 |
150分钟/8=18.75分钟 |
3 |
9 |
30分钟×3+20分钟×3+10分钟×3=180分钟 |
180分钟/9=20分钟 |
3 |
… |
|||
•当有1个人来理发的时候，需要10分钟的理发时间、平均响应时间为10分钟、实际并发数为1。
•当有2个人来理发的时候，2个人可以同时进行，共需要10×2=20分钟的理发时间、平均响应时间仍旧为20/2=10分钟、实际并发数为2。
•当有3个人来理发的时候，3个人仍旧可以同时进行，共需要10×3=30分钟的理发时间、平均响应时间仍旧为30/3=10分钟、实际并发数为3。
•当有4个人来理发的时候，3个人可以同时进行，但有1个人需要等到下一轮，这个时候需要20分钟×1+10分钟×3=50分钟的理发时间、平均响应时间为50/4=12.5分钟、由于理发师没有增加，实际并发数仍旧为3。
•当有5个人来理发的时候，3个人可以同时进行，2个人需要等到下一轮，这个时候需要20分钟×2+10分钟×3=70分钟的理发时间、平均响应时间为70/5=14分钟、由于理发师没有增加，实际并发数仍旧为3。
•当有6个人来理发的时候，3个人可以同时进行，3个人需要等到下一轮，这个时候需要20分钟×3+10分钟×3=90分钟的理发时间、平均响应时间为90/6=15分钟、由于理发师没有增加，实际并发数仍旧为3。
•当有7个人来理发的时候，3个人可以同时进行，3个人需要等到下一轮，1个人需要等到两轮，这个时候需要30分钟×1+20分钟×3+10分钟×3=120分钟的理发时间、平均响应时间为120/7=17.1分钟、由于理发师没有增加，实际并发数仍旧为3。
•当有8个人来理发的时候，3个人可以同时进行，3个人需要等到下一轮，2个人需要等到两轮，这个时候需要30分钟×2+20分钟×3+10分钟×3=150分钟的理发时间、平均响应时间为150/8=18.75分钟、由于理发师没有增加，实际并发数仍旧为3。
…
图3-8和图3-9分别是理发师模型平均响应时间、实际并发数与设置并发数对应曲线。
图3-8 理发师模型平均响应时间与设置并发数对应曲线图
3-9 理发师模型实际并发数与设置并发数对应曲线
在不到拐点的场景下，随着设置并发数的增加，平均响应时间基本保持不变，并且实际并发数与设置并发数保持一致；当超过拐点的场景下，随着设置并发数的增加，平均响应时间持续上升，而实际并发数在最高值保持不变。这与软件性能测试的情形是基本吻合的。如果要提高性能从硬件上考虑可以增加理发师，从软件上考虑可以加强理发师水平，减少给每一位顾客理发的时间。
3. 资源利用率（Resource Utilization）
资源利用率=资源实际使用量/总的资源可用量。资源利用率反映系统能耗指标，包括。
•CPU利用率。
•内存利用率。
•硬盘空间利用率。
•网络带宽利用率。
图3-10上面是某一进程对于CPU的利用率曲线图，图3-11下面是某一进程对于虚拟内存和物理内存的使用量的曲线图。
图3-10 CPU的资源利用率
图3-11 内存的资源利用率
4. 性能计数器（Performance Counter）
性能计数器是反映系统性能的重要参考指标。如何通过查看这些计数器来观察系统性能是需要通过平时积累的。关于Linux性能计数器的问题在Linux性能监控中结合命令行进行讨论，将在第2.2节中进行详细描述。Windows性能监控可以通过“开始菜单->控制面板->管理工具->性能”查看，如图3-12所示，将在第21节中进行详细描述。除了操作系统计数器，还有数据库计数器、中间件计数器、Web Service计数器等。
图3-12 在Windows下查看计数器
5. 并发用户数与在线用户数（Number of Concurrent Users、Number of Online Users）
并发用户数与在线用户数的区别在于，并发用户数是一批用户同时在干同一件事情（事务），如登录系统，可参见4.3.2-1章节介绍。而在线用户数指一些用户在系统上，有些在浏览网页、有些在查询、有些进入系统，还有些在做其他与系统无关的事情等。
案例3-8：并发用户数与在线用户数。
一个网站有3000人在线。30%的用户（900人）在浏览页面、20%的用户（600人）在填写订单、5%的用户（150人）在提交订单、15%的用户（450人）在查询订单、30%的用户（900人）干其他事情，比如做饭，照顾孩子。在这3000人里面，不考虑页面定时更新的情况下，实际对系统产生压力的仅仅为处于提交订单、查询订单的600人，占所有在线用户的20%。
6.思考时间（Tinking Time）
思考时间也称休眠时间，从业务角度来说，该时间指的是用户在操作时，每个请求之间的间隔时间。
案例3-9：思考时间
某个用户登录系统后，过了5秒，开始往模糊查询中输入查询内容，从输入到按点击用了10秒，查询结果出来后，停留了20秒又进入某个查询结果的详细页面。这里，登录后5秒，输入花费的10秒，停留的20秒都是思考时间。
在思考时间设置中LoadRunner提供了按照录制时间、录制时间的倍数、录制时间的某一百分比空间和一个固定的值4种方式。而在不加插件的情况下，JMeter只能设置一个固定的值。
