LR性能测试结果样例分析 -下 - 51Testing软件测试论坛

　　　系统资源图显示了在场景执行过程中被监控的机器系统资源使用情况，一般情况下监控机器的CPU、内存、网络、磁盘等各个方面。本次测试监控的是测试服务器的CPU使用率与内存使用率，以及处理器队列长度，具体的数据如图1- 13所示。

从图中可以看出，CPU使用率、可用物理内存、CPU的队列长度三个指标的曲线逗较为平滑，三者的平均值分别为：53.582%、83.456M、8.45，而测试服务器总的物理内存为384M，那么内存使用率为（384-83.456）/384=78.26%，根据本次性能测试要求的：CPU使用率不超过75%，物理内存使用率不超过70%这两点来看，内存的使用率78.26%大于预期的70%，故内存使用率不达标。根据Windwos资源性能指标的解释，一般情况下，如果“Processor Queue Length（处理器队列长度）”一直超过二，则可能表示处理器堵塞，我们这里监控出来的数值是8.45，而且总体上保持平衡，那么由此推断，测试服务器的CPU也可能是个瓶颈。同时在测试过程中，场景执行到23分半钟的时候，报出了错误！未找到引用源。的错误，意思是说被监控的服务器当前无法再进行计数器数据的获取了，所以，本次操作系统资源的监控只得到了场景执行的前23分半钟的数据。这样对本次测试结果有一定的影响。

测试项	目标值	实际值	是否通过
登录业务响应时间	<=3秒	2.298秒	Y
考勤业务响应时间	<=3秒	1.469秒	Y
登录业务成功率	100%	100%	Y
考勤业务成功率	100%	100%	Y
登录业务总数	30分钟完成2000	2163	Y
考勤业务总数	30分钟完成2000	2163	Y
CPU使用率	<75%	53.582%	Y
内存使用率	<70%	78.26%	N

从上表数据来看，本次测试总体上已经达到了预期的性能指标，但从其他的数据，比如CPU的队列长度、内存使用率来看，被测服务器的硬件资源需要提升。

　　　网页细分图可以评估页面内容是否影响事务响应时间。使用网页细分图，可以分析网站上有问题的元素（例如下载很慢的图像或打不开的链接）。

我们这里查看一下网页细分图中的“Page Download Time Breakdown”，点击错误！未找到引用源。左边的“New Graph”，出现图1- 14，展开“Web Page Diagnostics”前的加号，双击“Page Download Time Breakdown”，待出现“Page Download Time Breakdown”监控图后，点击【Close】按钮关闭添加监控图界面。

在监控图列表中，我们看到图1- 15，从图中我们看到，在所有的页面中，登录后的用个人面页面“http://192.168.0.52:8080/oa/oa.jsp”的下载时间最长。

图1- 16详细列出了每个页面所消耗的时间分布，图中每一个指标含义见表4所示。该表由LoadRunner使用手册提供。通过这些指标的数据，我们可以轻易的判断是哪个页面、哪个请求导致了响应时间变长，甚至响应失败。

名称	描述
Client Time	显示因浏览器思考时间或其他与客户端有关的延迟而使客户机上的请求发生延迟时，所经过的平均时间。
Connection Time	显示与包含指定URL的Web服务器建立初始连接所需的时间。连接度量是一个很好的网络问题指示器。此外，它还可表明服务器是否对请求做出响应。
DNS Resolution Time	显示使用最近的DNS服务器将DNS名称解析为IP地址所需的时间。DNS查找度量是指示 DNS解析问题或DNS服务器问题的一个很好的指示器。
Error Time	显示从发出HTTP请求到返回错误消息（仅限于HTTP错误）这期间经过的平均时间。
First Buffer Time	显示从初始HTTP请求（通常为GET）到成功收回来自Web服务器的第一次缓冲时为止所经过的时间。第一次缓冲度量是很好的Web 服务器延迟和网络滞后指示器。（注意：由于缓冲区大小最大为8K，因此第一次缓冲时间可能也就是完成元素下载所需的时间。）
FTP Autherntication Time	显示验证客户端所用的时间。如果使用 FTP，则服务器在开始处理客户端命令之前，必须验证该客户端。FTP验证度量仅适用于 FTP协议通信
Receive Time	显示从服务器收到最后一个字节并完成下载之前经过的时间。接收度量是很好的网络质量指示器（查看用来计算接收速率的时间 / 大小比率）。
SSL Handshaking Time	显示建立SSL连接（包括客户端hello、服务器hello、客户端公用密钥传输、服务器证书传输和其他部分可选阶段）所用的时间。此时刻后，客户端和服务器之间的所有通信都被加密。SSL握手度量仅适用于HTTPS通信。

对于本次测试，从网页细分图来看，基本上每个页面的加载时间都是预期范围内，oa.jsp页面因为集成了用户的个人工作平台，需要检索很多的数据，并合成了很多图片，所以相应的加载时间较长，这是正确的。

　　　上述所有的监控图形LoadRunner都可以提供，但对于某些测试监控图来说，LoadRunner就没有提供了，期望其新版支持这些功能，当然想监控Tomcat、Jboss或者其他的Web服务器可以SiteScope工具，这个工具配置较为复杂，根据个人需要吧。我这里监控Tomcat使用的是ManageEngine Applications Manager 8的试用版，测试结束后得出Tomcat的JVM使用率如图1- 17所示。

从图中我们可以明显看出，Tomcat的JVM使用率不断上升，配置Tomcat时共分配了100M左右的物理内存给其，测试初期使用的JVM相对来说较少，我们的测试场景是从15:58:40开始，到16:29:42结束，共历时31分2秒。从图中看到，从16:00到16:30这个时间内，也就是测试场景执行期间，JVM的使用率不断上升，并没有在请求达到均衡状态后也呈现一种平衡状态，所以，从这点可以推断，如果测试场景继续执行，或者加大并发数，最终必将导致Tomcat内存不够用而报出“Out Of Memory”内存溢出的错误。在正常情况下，内存的使用应该与“Hit per Second”、“Average Throughput (bytes/second)”等监控图的图形走势是一致的。

从上述过程可以得出一个结论，出现图1- 17中的问题，可能有两个原因：

1、为Tomcat分配更多的内存，如果是使用的catalina.sh或Catalina.bat启动的Tomcat，则可在这两个文件中添加“SET CATALINA_OPTS= -Xms300m–Xmx300m”，如果使用的winnt服务方式启动的Tomcat，则可在“运行”中输入“regedit”进入注册表，然后在“HKEY_LOCAL_MACHINE-->SOFTWARE-->Apache Software Foundation-->Process Runner 1.0-->Tomcat5-->Parameters”修改两个属性，一个是JvmMs，另外一个是JvmMx，如图1- 18所示。