LoadRunner性能测试结果分析（转载）

性能测试的需求指标：本次测试的要求是验证在30分钟内完成2000次用户登陆系统，而后进行考勤业务，最后退出，在业务操做过程当中页面的响应时间不超过3秒，而且服务器的CPU使用率、内存使用率分别不超过75%、70%

LoadRunner性能测试结果分析内容：

一、结果摘要

LoadRunner进行场景测试结果收集后，首先显示的该结果的一个摘要信息，如图1- 2所示。概要中列出了场景执行状况、“Statistics Summary（统计信息摘要）”、“Transaction Summary（事务摘要）”以及“HTTP Responses Summary（HTTP响应摘要）”等。以简要的信息列出本次测试结果。

 

图1- 2性能测试结果摘要图

场景执行状况：该部分给出了本次测试场景的名称、结果存放路径及场景的持续时间，如图1- 3所示。从该图咱们知道，本次测试从15:58:40开始，到16:29:42结束，共历时31分2秒。与咱们场景执行计划中设计的时间基本吻合。

 

图1- 3场景执行状况描述图

Statistics Summary（统计信息摘要）

该部分给出了场景执行结束后并发数、总吞吐量、平均每秒吞吐量、总请求数、平均每秒请求数的统计值，如图1- 4所示。从该图咱们得知，本次测试运行的最大并发数为7，总吞吐量为842,037,409字节，平均每秒的吞吐量为451,979字节，总的请求数为211,974，平均每秒的请求为113.781，对于吞吐量，单位时间内吞吐量越大，说明服务器的处理能越好，而请求数仅表示客户端向服务器发出的请求数，与吞吐量通常是成正比关系。

 

图1- 4统计信息摘要图

Transaction Summary（事务摘要）

该部分给出了场景执行结束后相关Action的平均响应时间、经过率等状况，如图1- 5所示。从该图咱们获得每一个Action的平均响应时间与业务成功率。

注意：由于在场景的“Run-time Settings”的“Miscellaneous”选项中将每个Action当成了一个事务执行，故这里的事务其实就是脚本中的Action。

 

图1- 5事务摘要图

HTTP Responses Summary（HTTP响应摘要）

该部分显示在场景执行过程当中，每次HTTP请求发出去的状态，是成功仍是失败，都在这里体现，如图5- 6所示。从图中能够看到，在本次测试过程当中LoadRunner共模拟发出了211974次请求（与“统计信息摘要”中的“Total Hits”一致），其中“HTTP 200”的是209811次，而“HTTP 404”则有2163，说明在本次过程当中，通过发出的请求大部分都能正确响应了，但仍是有部分失败了，但未影响测试结果，“HTTP 200”表示请求被正确响应，而“HTTP 404”表示文件或者目录未能找到。有朋友可能会问，这里出现了404的错误，为何结果还都经过了。出现这样问题的缘由是脚本有些页面的请求内容并不是关键点，好比可能请求先前的cookie信息，若是没有就从新获取，因此不会影响最终的测试结果。

 

图1- 6 HTTP响应摘要

经常使用的HTTP状态代码以下：

400 没法解析此请求。

401.1 未经受权：访问因为凭据无效被拒绝。

401.2 未经受权: 访问因为服务器配置倾向使用替代身份验证方法而被拒绝。

401.3 未经受权：访问因为 ACL 对所请求资源的设置被拒绝。

401.4 未经受权：Web 服务器上安装的筛选器受权失败。

401.5 未经受权：ISAPI/CGI 应用程序受权失败。

401.7 未经受权：因为 Web 服务器上的 URL 受权策略而拒绝访问。

403 禁止访问：访问被拒绝。

403.1 禁止访问：执行访问被拒绝。

403.2 禁止访问：读取访问被拒绝。

403.3 禁止访问：写入访问被拒绝。

403.4 禁止访问：须要使用 SSL 查看该资源。

403.5 禁止访问：须要使用 SSL 128 查看该资源。

403.6 禁止访问：客户端的 IP 地址被拒绝。

403.7 禁止访问：须要 SSL 客户端证书。

403.8 禁止访问：客户端的 DNS 名称被拒绝。

403.9 禁止访问：太多客户端试图链接到 Web 服务器。

403.10 禁止访问：Web 服务器配置为拒绝执行访问。

403.11 禁止访问：密码已更改。

403.12 禁止访问：服务器证书映射器拒绝了客户端证书访问。

403.13 禁止访问：客户端证书已在 Web 服务器上吊销。

403.14 禁止访问：在 Web 服务器上已拒绝目录列表。

403.15 禁止访问：Web 服务器已超过客户端访问许可证限制。

403.16 禁止访问：客户端证书格式错误或未被 Web 服务器信任。

403.17 禁止访问：客户端证书已经到期或者还没有生效。

403.18 禁止访问：没法在当前应用程序池中执行请求的 URL。

403.19 禁止访问：没法在该应用程序池中为客户端执行 CGI。

403.20 禁止访问：Passport 登陆失败。

404 找不到文件或目录。

404.1 文件或目录未找到：网站没法在所请求的端口访问。

须要注意的是404.1错误只会出如今具备多个IP地址的计算机上。若是在特定IP地址/端口组合上收到客户端请求，并且没有将IP地址配置为在该特定的端口上侦听，则IIS返回 404.1 HTTP错误。例如，若是一台计算机有两个IP地址，而只将其中一个IP地址配置为在端口80上侦听，则另外一个IP地址从端口80收到的任何请求都将致使IIS返回404.1错误。只应在此服务级别设置该错误，由于只有当服务器上使用多个IP地址时才会将它返回给客户端。

404.2 文件或目录没法找到：锁定策略禁止该请求。

404.3 文件或目录没法找到：MIME 映射策略禁止该请求。

405 用于访问该页的 HTTP 动做未被许可。

406 客户端浏览器不接受所请求页面的 MIME 类型。

407 Web 服务器须要初始的代理验证。

410 文件已删除。

412 客户端设置的前提条件在 Web 服务器上评估时失败。

414 请求 URL 太大，所以在 Web 服务器上不接受该 URL。

500 服务器内部错误。

500.11 服务器错误：Web 服务器上的应用程序正在关闭。

500.12 服务器错误：Web 服务器上的应用程序正在从新启动。

500.13 服务器错误：Web 服务器太忙。

500.14 服务器错误：服务器上的无效应用程序配置。

500.15 服务器错误：不容许直接请求 GLOBAL.ASA。

500.16 服务器错误：UNC 受权凭据不正确。

500.17 服务器错误：URL 受权存储没法找到。

500.18 服务器错误：URL 受权存储没法打开。

500.19 服务器错误：该文件的数据在配置数据库中配置不正确。

500.20 服务器错误：URL 受权域没法找到。

500 100 内部服务器错误：ASP 错误。

501 标题值指定的配置没有执行。

502 Web 服务器做为网关或代理服务器时收到无效的响应。

二、并发数

“Running Vusers（运行的并发数）”显示了在场景执行过程当中并发数的执行状况。它们显示Vuser的状态、完成脚本的Vuser的数量以及集合统计信息，将这些图与事务图结合使用能够肯定Vuser的数量对事务响应时间产生的影响。图1- 7显示了在OA系统考勤业务性能测试过程当中Vusers运行状况，从图中咱们能够看到，Vusers的运行趋势与咱们场景执行计划中的设置是同样，代表在场景执行过程当中，Vusers是按照咱们预期的设置运行的，没有Vuser出现运行错误，这样从另外一个侧面说明咱们的参数化设置是正确的，由于使用惟一数进行参数化设置，若是设置不正确，将会致使Vuser运行错误。在脚本中咱们加入了这样一段代码：

 if (atoi(lr_eval_string("{num}")) > 0){

              lr_output_message("登陆成功，继续执行.");

              }

        else{

              lr_error_message("登陆失败，退出测试");

              return -1;

        }

上述代码的意思是说，若是登陆失败了，就退出脚本的迭代，那么什么缘由可能会致使登陆失败呢？就是咱们前面参数化的设置，一旦Vuser分配不到正确的登陆帐号，就可能致使登陆失败，从而引发Vuser中止运行。因此，从图5- 7的表现，能够认为参数化是没有问题的。

 

图1- 7运行的并发数图

测试脚本中咱们还使用了集合点，那么这里还能够看看集合点在场景执行过程当中的表现，点击左边的“New Graph”，出现图5- 8，展开“Vusers”前的加号，双击“Rendezvous”，出现集合点的图形后，点击【Close】，关闭添加新图界面。

 

图1- 8添加集合点统计图

集合点的图形如图1- 9所示，从图中能够看到，全部用户到达集合点后，马上就释放了。与以前设定的集合点策略设置“全部运行用户到达后释放“是一致的。假设这样的一种状况，Running的Vusers有10个，集合点策略设置是“全部运行用户到达后释放”，而集合点图形显示的最大释放Vusers是7个，那么就表示有些Vuser超时了，引发超时的缘由多是Vuser获得的响应超时了，能够结合平均事务响应时间再详细分析缘由。

 

 图1- 9集合点状态图

咱们本次测试Running Vusers与集合点是一致，说明整个场景执行过程当中，并发数用户的执行正确，OA系统测试服务器可以应付7个并发用户的业务操做。

 

三、平均事物响应时间

在性能测试要求中咱们知道，有一项指标是要求登陆、考勤业务操做的页面响应时间不超过3秒，那么本次测试是否达到了这个要求呢？咱们先来看“Average Transaction Response Time（平均事务响应时间图）”（图1- 10），这张图是平均事务响应时间与结果摘要中的“Transaction Summary”合成的。

 

 图1- 10平均事务响应时间图

从图形下部咱们能够看到，登陆部分对应的Action是“submit_login”，考勤业务提交对应的Action是“submit_sign”，他们的“Average Time（平均响应时间为）”分别是4.425秒与0.848秒，从这两个数值来看，考勤业务的事务响应时间0.848秒小于预期的3秒，达到了要求，而登陆是4.425秒，大于预期的3秒，不符合要求。这样的结果是不正确的，由于在统计的登陆业务的时候，咱们没有去除思考时间，因此，登陆功能的实际事务时间应该是4.425秒-3秒=1.425秒，小于预期的3秒，故登陆业务的事务响应时间也达到了咱们的要求。在平时的性能测试活动中，统计结果的时候须要去掉思考时间，加上思考时间是为了真实的模拟用户环境，统计结果中除去思考时间是为了更真实的反映服务器的处理能力，二者并不矛盾。

看完了“Average Time”，咱们再看“90 Percent Time”，这个时间从某种程度来讲，更准确衡量了测试过程当中各个事务的真实状况，表示90%的事务，服务器的响应都维持在某个值附近，“Average Time”值对于平均事务响应时间变更趋势很大的状况统计就不许确了，好比有三个时间：1秒、5秒、12秒，则平均时间为6秒，而另一种状况：5秒、6秒、7秒，平均时间也为6秒，显然第二种比第一种要稳定多了。因此，咱们在查看平均事务响应时间的时候，先看总体曲线走势，若是总体趋势比较平滑，没有忽上忽下的波动状况，取“Average Time”与“90 Percent Time”均可以，若是总体趋势毫无规律，波动很是大，咱们就不用“Average Time”而使用“90 Percent Time”可能更真实些。

从图1- 10能够看出，全部Action平均事务响应时间的趋势都很是平滑，因此使用“Average Time”与“90 Percent Time”差异不是很大，用哪一个均可以。这里是使用最经常使用的统计方法“90 Percent Time”。登陆业务的“90 Percent Time”是5.298秒-3秒（思考时间）=2.298秒，考勤业务的“90 Percent Time”是1.469秒，没有思考时间，那么就是实打实的啦。根据上面的计算，本次测试结果记录如表1所示。

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

表1测试结果对照表一

 

四、每秒点击数

“Hits per Second（每秒点击数）”反映了客户端每秒钟向服务器端提交的请求数量，若是客户端发出的请求数量越多，与之相对的“Average Throughput (bytes/second)”也应该越大，而且发出的请求越多会对平均事务响应时间形成影响，因此在测试过程当中每每将这三者结合起来分析。图1- 11显示的是“Hits per Second”与“Average Throughput(bytes/second)”的复合图，从图中能够看出，两种图形的曲线都正常而且基本一致，说明服务器能及时的接受客户端的请求，并可以返回结果。若是“Hits per Second”正常，而“Average Throughput (bytes/second)”不正常，则表示服务器虽然可以接受服务器的请求，但返回结果较慢，多是程序处理缓慢。若是“Hits per Second”不正常，则说明客户端存在问题，那种问题通常是网络引发的，或者录制的脚本有问题，未能正确的模拟用户的行为。具体问题具体分析，这里仅给出一些建议。

 

 图1- 11每秒点击数与每秒吞吐量复合图

对于本次测试来讲，“Hits per Second”与“Average Throughput (bytes/second)”都是正常的，并且总体表现仍是不错的。

通常状况下，这两种指标用于性能调优，好比给定了几个条件，去检测另一个条件，用这两个指标衡量，每每起到很好的效果。好比要比较某两种硬件平台的优劣，就可使用相同的配置方法部署软件系统，而后使用相同的脚本、场景设计、统计方法去分析，最终得出一个较优的配置。

 

五、业务成功率

“业务成功率”这个指标在不少系统中都说起到，好比电信的、金融的、企业资源管理的等等。举个例子，咱们楼下的建行，假如天天的业务类别是这样的：20个开户，5个销户，300个存款，500取款，100个汇款等，那么在作他们的营业系统测试时就须要考虑业务成功率了，通常不得低于98%。具体的业务成功率是什么意思呢？排除那些复杂的业务，好比异步处理的业务（移动的套卡开通就是异步的），业务成功率就是事务成功率，用户通常把一个Aciton当作一笔业务，在LoadRunner场景执行中一笔交易称为一个事务。因此说业务成功率其实就是事务成功率、经过率的意思。在“Transaction Summary”中咱们能够很明确的看到每一个事务的执行状态，如图1- 12所示。

 

 图1- 12事务状态统计图

从图中能够看出，全部的Aciton都是绿色的，即表示为Passed，同时除了vuser_init与vuser_end两个事务，其余的事务经过数为2163，也就代表在30分钟的时间里，共完成了2163次登陆考勤业务操做。那么根据这些能够判断本次测试登陆业务与考勤业务的成功率是100%，再次更新测试结果记录表如表2所示。

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

表2测试结果对照表二

 

六、系统资源

系统资源图显示了在场景执行过程当中被监控的机器系统资源使用状况，通常状况下监控机器的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，从图中咱们看到，在全部的页面中，登陆后的用我的面页面的下载时间最长。

 

图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中的问题，可能有两个缘由：

一、Tomcat的内存分配不足；

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

解决方法：

一、  为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所示。

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

 

 图1- 18修改Tocat的JVM数据

 

九、数据库服务器

数据库服务器资源监控相对来讲就复杂的多了，如今经常使用的数据有Mysql、SQL Server、Oracle、DB2等，LoadRunner提供对后面几种数据库的监控方法，但对Mysql没有提供对应的监控方法。他不提供，我们就本身找监控工具，我这里使用的是Spotlight，该工具监控数据库的好处是配置链接简单，不只能监控数据库，还能监控操做系统的资源，监控结果直观明了。错误！未找到引用源。显示了Mysql数据库在场景执行过程当中SQL语句的执行状况，从图中能够看到，“Selects（查询）”与“Inserts（插入）”两种语句执行的趋势在场景执行过程当中是比较平滑，而且测试中没有错误发现，也就说明在处理相关业务时Mysql的处理是正常的。假如这两种SQL语句任何一个出现波动很大的状况，就能够推出在场景执行过程当中存在页面错误，由于这些语句不执行，就代表某些页面未被加载或者某些功能未被使用。在本次测试中，OA系统的“oa.jsp”页面有大量的“Selects（查询）”语句，而考勤操做则是“Inserts（插入）”，因此，只要有一方出问题，必然表示测试过程当中存在页面打不开或者考勤不成功的错误。

经过前面的分析，在查看错误！未找到引用源中的SQL语句执行状态，本次测试在页面访问、功能执行方面是没有问题的。