LR性能测试结果样例分析 -下

天外繁星

• 系统资源

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

图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所示。

测试项	目标值	实际值	是否通过
登录业务响应时间	<=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

表3测试结果对照表三

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

• 网页细分图

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

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

图1- 14添加网页细分图

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

图1- 15网页下载时间细分图

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

图1- 16 oa.jsp页面下载时间分布图

名称	描述
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通信。

表4网页下载时间细分指标说明

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

• Web服务器资源

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

图1- 17 Tomcat JVM使用率监视图

从图中我们可以明显看出，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的内存分配不足；

2、  程序代码有错误，可能导致内存泄露。

解决方法：

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所示。

2、  检查程序代码，使用一些内存泄露检查工具进行清查。

图1- 18修改Tocat的JVM数据

lsekfe

不错 支持分享~~

margie888

分析得不错哟，支持

margie888

支持

sheiss

从jvm使用情况来看，似乎没有gc。如果正常进行gc，不一定会内存溢出吧？
新手，望指教。

annkingup

回复 5# sheiss


    如果有GC的话,JVM内存使用率是有一个波动. 楼主的图是持续上升的.

annkingup

回复 5# sheiss

    补充一下:


    如果有GC的话,JVM内存使用率是有一个波动.(而且最终趋于平稳)      而楼主的图是持续上升的. 非常像程序有内存泄漏的情况. 导致JVM的GC机制失效.

sheiss

回复  sheiss

    补充一下:


    如果有GC的话,JVM内存使用率是有一个波动.(而且最终趋于平稳)    ...
annkingup 发表于 2014-5-23 14:30

不太理解“最终趋于平稳”的意思。是指内存使用率先上升然后GC机制起作用，使用率下降，然后再上升再下降这种动态的平稳吗？

annkingup

回复 8# sheiss


    是的 . 动态平衡.  趋势线总体不往上长.

森林一木

楼主，介个，好像是俺写的web项目测试实战里的分析过程吧。。。。

初学者song

不错哎

初学者song

我想看看你写的，但是我找不到

lishuoyiyu

不错，谢谢分享

筱涵木兰

不错，lr结果分析，很好

金小言

回复 10# 森林一木

张亚洲

赞

mymagic

楼主，介个，好像是俺写的web项目测试实战里的分析过程吧。。。。
森林一木 发表于 2014-6-4 15:05

    被窃取了。。

esse

谢谢分享，转载注明出处

43220056

回复 5# sheiss


    赞同你的观点，楼主这个图看不出有内存泄漏或者内存不足吧。。应该看HEAP USAGE AFTER GC 之类的图吧？看看每次FULL GC之后的内存使用点是不是趋势上升，如果是的话才能说明是内存泄漏吧。不知道这个方法对不对。

shigui3615

仅从“图1- 17 Tomcat JVM使用率监视图”来断定有内存泄露，这个结论下得过早了。如楼上所说的，内存还没有出现GC。
通常，要判断程序是否有内存泄露，是要经过长时间的测试，观察内存每次GC后，内存使用率是否能够回到最初值，如果每次内存GC(内存回收)都不完全，就会导致所能分配的内存越来越少，最终导致响应时间变成，JVM停止运行，系统崩溃等。内存GC的周期有长有短，有些公司的标准是半个小时FGC一次算正常。Linux系统下，用jstat - gcutil xxxxx 命令可以看出。
第二点，内存使用率超过预期值就判定内存不足，也不科学，这个还要结合IO的使用情况来判断。对JVM来说，内存在什么时候回收，可以设定的，如果，你设定内存使用率在80%的时候回收，那么，你这个测试结果看到的内存使用率超过预期值后还在上升，属于正常情况。