响应时间=用户响应时间+前端响应时间+网络响应时间+服务器端响应时间+数据库响应时间,是反映系统处理效率的指标之一。
响应时间是从开始到完成某项工作所需时间的度量。嵌入式产品,响应时间不包括人的反应时间,而对于其他产品,大多数都是人机交互的,响应时间体现在人的直观体验感受。在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)用户接收到显示信息的时间。
吞吐率是单位时间内的吞吐量。吞吐量是服务器所能处理事务的能力。吞吐率的单位为字节数/秒、业务数/秒、点击数/秒、请求数/秒。随着负载的增加,吞吐率往往增长到一个峰值后,然后下降,队列变长。注意:在性能测试领域吞吐量是没有意义的,吞吐率才有意义。比如说某台服务器可以处理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 理发师模型实际并发数与设置并发数对应曲线
在不到拐点的场景下,随着设置并发数的增加,平均响应时间基本保持不变,并且实际并发数与设置并发数保持一致;当超过拐点的场景下,随着设置并发数的增加,平均响应时间持续上升,而实际并发数在最高值保持不变。这与软件性能测试的情形是基本吻合的。如果要提高性能从硬件上考虑可以增加理发师,从软件上考虑可以加强理发师水平,减少给每一位顾客理发的时间。
资源利用率=资源实际使用量/总的资源可用量。资源利用率反映系统能耗指标,包括。
•CPU利用率。
•内存利用率。
•硬盘空间利用率。
•网络带宽利用率。
图3-10上面是某一进程对于CPU的利用率曲线图,图3-11下面是某一进程对于虚拟内存和物理内存的使用量的曲线图。
图3-10 CPU的资源利用率
图3-11 内存的资源利用率
性能计数器是反映系统性能的重要参考指标。如何通过查看这些计数器来观察系统性能是需要通过平时积累的。关于Linux性能计数器的问题在Linux性能监控中结合命令行进行讨论,将在第2.2节中进行详细描述。Windows性能监控可以通过“开始菜单->控制面板->管理工具->性能”查看,如图3-12所示,将在第21节中进行详细描述。除了操作系统计数器,还有数据库计数器、中间件计数器、Web Service计数器等。
图3-12 在Windows下查看计数器
并发用户数与在线用户数的区别在于,并发用户数是一批用户同时在干同一件事情(事务),如登录系统,可参见4.3.2-1章节介绍。而在线用户数指一些用户在系统上,有些在浏览网页、有些在查询、有些进入系统,还有些在做其他与系统无关的事情等。
案例3-8:并发用户数与在线用户数。
一个网站有3000人在线。30%的用户(900人)在浏览页面、20%的用户(600人)在填写订单、5%的用户(150人)在提交订单、15%的用户(450人)在查询订单、30%的用户(900人)干其他事情,比如做饭,照顾孩子。在这3000人里面,不考虑页面定时更新的情况下,实际对系统产生压力的仅仅为处于提交订单、查询订单的600人,占所有在线用户的20%。
思考时间也称休眠时间,从业务角度来说,该时间指的是用户在操作时,每个请求之间的间隔时间。
案例3-9:思考时间
某个用户登录系统后,过了5秒,开始往模糊查询中输入查询内容,从输入到按点击用了10秒,查询结果出来后,停留了20秒又进入某个查询结果的详细页面。这里,登录后5秒,输入花费的10秒,停留的20秒都是思考时间。
在思考时间设置中LoadRunner提供了按照录制时间、录制时间的倍数、录制时间的某一百分比空间和一个固定的值4种方式。而在不加插件的情况下,JMeter只能设置一个固定的值。