LoadRunner性能测试实战.docx
《LoadRunner性能测试实战.docx》由会员分享，可在线阅读，更多相关《LoadRunner性能测试实战.docx（63页珍藏版）》请在冰点文库上搜索。
LoadRunner性能测试实战
LoadRunner性能测试实战
5.1.2Analysis使用基础
5.1.2 Analysis使用基础
在测试场景执行过程中，LoadRunner采集了虚拟用户、操作系统、应用服务器等各种运行数据，这些数据成为分析系统性能的重要参考资料。
当测试场景运行结束后，就可以通过Analysis对这些测试结果进行专门的分析，以发现系统的潜在问题。
LoadRunner的Analysis是一个独立模块，本节将介绍它的主要功能以及基本使用方法。
在后面的5.2节中，将详细介绍如何借助各类数据图表来分析系统的性能问题。
Analysis的基本功能及使用
启动Analysis有4种方式：
在Controller启动场景前选中其菜单的“Run→AutoLoadAnalysis”；在Controller工具栏中点击第一个
图标；在Controller工具栏中点击第二个
图标；从开始菜单依次点击“MercuryLoadRunner→Applications→Analysis”。
其中，前两种方式在打开Analysis后会自动分析当前场景的运行结果，后两种方式仅打开Analysis应用程序，需要手动选择测试结果文件来产生分析图。
在测试结束并完成测试结果数据收集后，就可以启动Analysis打开测试结果文件，将其导入MicrosoftAccess数据库，然后按照设置的模板打开默认的结果分析图。
通常的分析器默认界面如图5-4所示。
利用Analysis进行分析的第一步是查看分析概要报告（AnalysisSummary），图5-4中显示的即为分析概要报告。
分析概要报告展示了场景运行的统计信息、事务响应时间概述、HTTP响应概述（对于Web测试）等。
在分析概要结果中，重点查看虚拟用户的运行情况和事务综述。
对虚拟用户，主要查看最大并发用户数目；对事务综述，则要查看最大、最小、平均、“90％”事务最大响应时间、通过事务数量、失败事务数量等。
图5-4 Analysis的默认分析概要界面
在图5-4所示的Analysis界面中，点击
将进入到图5-5所示的新的分析图界面，在这里可以查看Analysis提供的全部分析图。
从图5-5中可以看出，对于一个和Web相关的测试结果，Analysis主要提供了六大类分析图。
下面简要介绍各类分析图的含义及用途。
图5-5 打开新的分析图界面
虚拟用户（Vusers）图 虚拟用户图分为运行状态的虚拟用户图、虚拟用户概要图和集合点图3类。
主要借助其查看场景与会话的虚拟用户行为。
Errors图 Errors图主要有错误统计、每秒错误数量两类。
借助Errors图可以发现服务器什么时间发生错误以及错误的统计信息，可以分析服务器的处理能力。
事务（Transactions）图 Analysis和事务相关的分析图表有事务综述图、事务平均响应时间图、每秒通过事务数图、每秒通过事务总数图、事务性能摘要图、事务响应时间与负载分析图、事务响应时间（百分比）图、事务响应时间分布图等，通过这些图表可以很容易分析应用系统事务的执行情况。
Web资源（WebResources）图 Web资源图主要有Web服务器的吞吐率图、点击率图、返回的HTTP状态代码图、每秒HTTP响应数图、每秒重试次数图、重试概述图、服务器连接数概要图、服务器每秒建立的连接数量图等。
借助Web资源图，可以深入地分析服务器的性能。
网页细分（WebPageBreakdown）图 在Controller中启动网页细分功能后，才可以在Analysis中查看网页细分图，启动细分功能的具体步骤是：
在Controller菜单中选择“Diagnostics→Distribution”进入图5-6所示的界面，在图5-6中同时选中“Enablethefollowingdiagnostics”和“WebPageDiagnostics（MaxAllowedDistribution10%）”复选框。
图5-6 启动网页细分图功能
网页细分图主要有页面分解总图、页面组件细分图、页面组件分解（随时间变化）图、页面下载时间细分图、页面下载时间细分（随时间变化）图、第一次缓冲时间细分图、第一次缓冲时间细分（随时间变化）图、已下载组件大小图。
借助网页细分图可以分析页面元素是否影响事务响应时间。
系统资源（SystemResources）图 系统资源图显示在场景运行期间，由联机监控获得的系统资源使用情况。
要想获得系统资源图，必须预先指定相关的计数器。
关于监控系统资源的方法，可以参考第3章的相关内容。
在5.4节中，我们将详细介绍如何查看各类具体的分析图。
如何看Analysis分析图
面对Analysis提供的几十个测试结果分析图，很多人会感到无所适从，不知如何入手。
实际上，性能测试分析要求执行人员更加谨慎和细心，不能放过任何一个缺陷，尤其要深入到系统内部来进行分析。
同时，当分析结果时还应该借助Analysis以外的各种分析工具。
例如，可以借助Oracle提供的监控与分析工具，也可以借助WebLogic提供的监控与分析工具，要想尽一切办法来发现系统瓶颈。
在5.1.3节的案例中，Oracle自带的SQL分析功能对性能定位起了至关重要的作用。
下面介绍一些通用的性能测试分析流程。
第一步：
从分析Summary的事务执行情况入手。
Summary主要是判定事务的响应时间与执行情况是否合理。
如果发现问题，则需要做进一步分析。
通常情况下，如果事务执行情况失败或响应时间过长等，都需要做深入分析。
下面是查看分析概要时的一些原则：
用户是否全部运行，最大运行并发用户数（MaximumRunningVusers）是否与场景设计的最大运行并发用户数一致。
如果没有，则需要打开与虚拟用户相关的分析图，进一步分析虚拟用户不能正常运行的详细原因；
事务的平均响应时间、90％事务最大响应时间用户是否可以接受。
如果事务响应时间过长，则要打开与事务相关的各类分析图，深入地分析事务的执行情况；
查看事务是否全部通过。
如果有事务失败，则需要深入分析原因。
很多时候，事务不能正常执行意味着系统出现了瓶颈；
如果一切正常，则本次测试没有必要进行深入分析，可以进行加大压力测试；
如果事务失败过多，则应该降低压力继续进行测试，使结果分析更容易进行；
……
上面这些原则都是分析Summary的一些常见方法，读者应该灵活使用并不断地进行总结与完善，尤其要注意结合实际情况，不能墨守成规。
第二步：
查看负载发生器和服务器的系统资源情况。
查看分析概要后，接下来要查看负载发生器和待测服务器的系统资源使用情况：
查看CPU的利用率和内存使用情况，尤其要注意查看是否存在内存泄漏问题。
这样做是由于很多时候系统出现瓶颈的直接表现是CPU利用率过高或内存不足。
应该保证负载发生器在整个测试过程中其CPU、内存、带宽没有出现瓶颈，否则测试结果无效。
而待测试服务器，则重点分析测试过程中CPU和内存是否出现了瓶颈：
CPU需要查看其利用率是否经常达到100%或平均利用率一直高居95％以上；内存需要查看是否够用以及测试过程是否存在溢出现象（对于一些中间件服务器要查看其分配的内存是否够用）。
第三步：
查看虚拟用户与事务的详细执行情况。
在前两步确定了测试场景的执行情况基本正常后，接下来就要查看虚拟用户与事务的执行情况。
对于虚拟用户，主要查看在整个测试过程中是否运行正常，如果有较多用户不能正常运行，则需要重新设计场景或调整用户加载与退出方式再次进行测试。
对于事务，重点关注整个过程的事务响应时间是否逐渐变长以及是否存在不能正常执行的事务。
总之，任何用户或事务的执行细节都应该认真分析，不可以轻易忽略。
图5-7所示的就是一个性能逐步下降的服务器，需要进一步分析其性能下降的原因，例如查找是否存在内存泄漏问题；图5-8则是一个性能相对稳定的服务器，但是响应时间偏大，这时需要分析程序算法是否存在缺陷或服务器参数的配置是否合理。
图5-7 性能逐步下降的服务器
下面是虚拟用户与事务分析的常用准则：
虚拟用户如有失败，则要查明原因；
在整个测试过程中，所有的虚拟用户是否一直稳定运行并成功执行全部事务。
如果仅有一个用户或部分用户能够正常运行，则说明测试脚本可能存在问题；
对于失败的事务首先要分析其失败原因，接着要查看事务的失败是否导致了用户失败；
判断用户是否可以接受事务平均响应时间值以及90％用户的最大响应时间值；
查看整个测试过程的事务平均响应时间是否逐步变大，正常情况下，事务平均响应时间的变化应该是接近于平行X轴的一条直线；
事务响应时间是否在整个测试过程中随着用户的增加而线性变短。
正常情况应该是，当一定范围内的用户并发时，事务响应时间应不会有太大变化；
服务器每秒通过的事务总数、某一事务每秒通过数是否稳定，如果整个测试过程基本不变，则要分析是服务器达到了处理上限，还是Generator产生的压力达到了上限；
按照迭代次数来运行的场景，要分析通过的事务总数是否与设定的一致。
如果不一致，则可能是测试脚本存在错误，也可能是待测试程序存在功能错误，应该在调整后再次进行测试；
……
图5-8 性能稳定的服务器
Analysis对虚拟用户和事务提供了非常强大的跟踪功能，可以跟踪每一个用户及其相关事务的执行情况。
这些内容可以在Analysis菜单“Reports→CrystalReport”下找到。
这部分内容将在5.3节介绍。
第四步：
查看错误发生情况。
整个测试过程的错误发生情况是分析的重点。
下面查看错误发生情况的常用准则：
查看错误发生曲线在整个测试过程中是否有规律变化，如果是，则意味着程序在并发处理方面存在一定的缺陷。
如图5-9所示的每秒缺陷数量曲线很有规律，这是因为服务器定期生成缓存文件导致用户不能正常访问而产生的错误；
图5-9 规律变化的每秒错误数曲线图
查看错误分类统计，作为优化系统的参考。
例如Web性能测试，当出现瓶颈时往往需要查看服务器的错误统计信息结果：
如果“超时错误”达到90％以上，可能需要提高硬件配置；如果有较多的“内部服务器错误”，则可能是程序方面存在问题。
第五步：
查看Web资源与细分网页。
本步骤仅适用于Web性能测试。
查看Web资源图时，往往需要结合前面对虚拟用户以及事务响应时间的分析结果，重点分析服务器的稳定性。
对于网页细分功能则应遵循如下原则：
首先分析从用户发出请求到收到第一个缓冲为止，哪些环节比较耗时；其次找出页面中哪些组成部分对用户响应时间影响较大；在页面的性能问题定位后，就可以采取相关的解决方案。
我们将在5.2节对Web资源和网页细分进行更加详细的介绍。
字号：
大大 中中 小小
LoadRunner性能测试实战
5.1.3一个视频网站例子
2007-9-1715:
25:
00
5.1.3 一个视频网站例子
项目背景信息
近两年，随着网络的发展，视频网站如雨后春笋般出现。
尤其一些热门的视频网站，拥有巨大的用户群体。
如一些知名电视台的宽频网站，在社会发生热点新闻期间的并发用户访问数量会达到百万级以上。
巨大的并发访问量对系统的性能提出了非常高的要求。
本案例探讨的是一个已经上线的视频网站遇到的性能问题，该系统的设计目标是每天150万的PV（页面浏览）量。
在上线后，由于用户并发量较大，CPU的利用率经常高居100％，导致Oracle数据库发生停止服务的现象。
数据库不工作，网站运营人员就无法维护系统，甚至导致终端用户不能正常访问网站。
显然，这类问题是不能容忍的。
在探讨性能测试工作之前，先简要介绍这个系统的体系结构，其功能点将在后面的内容中陆续介绍。
整个系统由下面两块组成：
视频发布系统：
该系统是一个成型的产品，主要功能是建立一个运营平台，把视频发布到系统中，并为门户提供接口。
本系统已经有多家成功应用的案例。
网站门户：
对视频发布系统进行二次开发后实现的一个应用。
借助视频发布平台提供的接口，门户实现了和视频发布系统所维护的运营平台之间的信息交互。
网站的用户主要通过门户来欣赏视频。
下面开始探讨如何测试系统的性能问题。
实验室的测试执行与结果分析
对本系统而言，由于已经发现了问题，所以性能测试的目标非常明确，就是要找出导致数据库停止服务的原因。
而分析这类问题时，很容易想到两个常见的原因：
程序算法上的缺陷或数据库配置不正确。
算法上的缺陷会导致CPU资源过度消耗，而配置不正确也会引起数据库系统运行异常。
因此，性能测试设计和实施将围绕这两个目标来进行。
下面详细介绍实验室的性能测试过程。
1.测试用例设计
由于问题出在数据库上，因此测试用例应该针对数据库来进行。
数据库的测试通常会分为下面三个步骤：
首先，把数据库的操作分为Insert、Update、Delete、Select四种，分别隔离进行测试，并定位哪种操作容易引起问题；
其次，把用户的日常操作模拟出来，也就是把用户对数据库的操作组合起来进行测试；
最后，做一些疲劳强度或大数据量的压力测试，以使问题快速重现。
确定了整体方案后，接下来就要确定测试过程需要模拟哪些用户操作。
分析整个系统的结构，可以看出视频发布系统出问题的可能性不大，因为这是一个成型的产品。
因此，问题更可能会出现在网站的门户或门户与视频发布系统的接口上。
经过进一步的分析，了解到网站门户用户访问量主要有三个页面：
视频首页：
视频首页是导航页面，主要操作有查找热点视频或自己关注的视频、进入二级分类页面、进入播放页面等。
收费播放页面：
付费用户播放视频时进入的页面。
免费播放页面：
用户播放免费视频时进入的页面。
这三个页面应该是重点测试的对象，用户日常操作组合测试、疲劳强度与大数据量测试都应该针对它们进行。
确定了测试内容后，就可以开始性能测试的实施了。
2.测试实施过程
不难看出，实验室测试是一个紧急的性能测试任务，因此没有时间进行正规的规划与设计，更多的是一种应变测试。
为了保证系统的“正常”运行，环境设在了实验室里，配置如表5-1所示。
表5-1 测试硬件配置
硬件配置
软件配置
数据库服务器
服务器：
两台Dell2850
CPU：
Xeon3.0GB´2
内存：
2GB
操作系统：
企业版Windows2003（SP1）
数据库：
Oracle10g
应用服务器
操作系统：
企业版Windows2003（SP1）
WebServer：
IIS6.0
作者在《Web性能测试实战》一书中曾经讨论过，由于硬件环境的差异，实验室里的调优只能作为上线后的参考。
实验室测试比较适合找出由软件自身缺陷引起的性能问题，较容易发现一些算法方面的缺陷。
常规并发用户测试
由于实验室与用户现场的硬件环境差别较大，因此应该先在实验室中进行“预测试”，看看系统在实验室中的性能表现，为后面的测试提供参考。
在本案例中，先选择50个并发用户来观察系统的性能表现，压力持续时间为30分钟。
注意：
读者碰到类似项目时可以根据系统自身的特点来选择并发用户数量，这里的50只是个参考。
经过测试后，利用Analysis进行分析，得到了如图5-10的测试结果摘要。
从图中可以看出：
视频首页（Index页面）不能访问，收费播放页面（Play访问）的平均访问时间为181.834秒。
图5-10 50个并发用户的预测试结果
由此不难得出结论：
这是一个过于缓慢的系统！
需要进行调整后才能正常开展测试工作。
通常情况下，对这类系统进行调整首先应从系统的参数配置或硬件配置入手，然后分析软件自身的原因。
这样做的原因是参数配置不正确的错误很容易纠正，也是常见的性能问题，而分析软件本身则是后面测试工作的主要内容。
因此，在查看了Oracle的服务器配置后，立刻发现了一个参数配置问题：
Oracle数据库的运行模式是“专有服务器模式”！
而“共享服务器模式”才是更适合大规模并发的模式。
关于Oracle服务器的运行模式
在专用服务器模式下，用户连接所需要的全部资源在PGA中进行分配。
该内存区为指定私有连接，其他进程不能访问。
专用连接采用一对一的连接方式，能很快地响应用户的请求。
但是，当用户连接过多时，由于要对每一个用户连接分配资源，因此，连接个数受硬件的限制比较大。
为了克服这种情况，Oracle提供了共享服务器运行模式，即用一个服务器的进程响应多个用户连接。
只要实例一启动，就分配指定数量的服务器进程，所有用户的连接以排队的方式由分配器指定给服务器进程，其他的进程排队等待。
只要用户的请求执行完，就会马上断开连接，分配器会把空闲的服务器进程分配给其他排队的进程。
因此，首先要把Oracle的运行模式调整为“共享服务器模式”再进行测试。
分析“Summary”的意义
从上面的内容可以看出，“Summary”的分析结果决定了是否继续进行后面的工作。
在本案例中，通过“Summary”看出系统性能非常令人不满意，因此没有必要进行深入分析。
正确的做法是立刻采取调优措施，否则测试工作将无法正常开展下去。
独立场景测试 下面是Oracle调整为“共享服务器模式”后的测试实施过程。
为了更好地对问题定位，测试只针对播放页面来进行。
图5-11是800个用户并发、压力持续30分钟的测试结果综述。
从图5-11中可以看出，“Action”事务即打开播放页面的平均时间是1.354秒，这是非常好的结果。
但是应该注意到：
半小时内有超过17万个播放页面不能正常打开，同时计算出为“打开播放页面”事务的通过率为82%。
82%的事务通过率标志着后续的性能测试任务十分艰巨，而半小时内超过17万个播放页面不能正常打开，是任何视频网站都不能接受的。
为了让问题更好地暴露出来，我们又进行了一次更长时间的场景测试：
压力持续时间增加到三倍，即1.5个小时；并发用户增加到了900个。
测试结果如图5-12所示。
与图5-11的测试结果相比，得到如下结论：
“打开播放页面”事务的平均响应时间稍稍变大，这是用户数量变大的正常反应；事务通过率85%与82%相比没有太大变化。
稍稍提高的通过率很可能是由于测试时间较长、打开的部分页面存在于服务器缓存中造成的。
图5-11 共享模式下800个用户的并发测试结果
图5-12 共享模式下900个用户的并发测试结果
这时，打开Oralce的管理工具，借助Oralce提供的工具进行分析。
结果发现了五个问题！
如图5-13所示。
图5-13 数据库分析的结果
打开图5-13中的“发现SQL语句消耗了大量数据库时间”链接进行查看，发现Oracle找出了三个SQL语句的问题，而这三个语句恰恰是播放页面频繁使用的语句！
终于找到了程序本身的一个原因：
SQL语句消耗了大量的数据库时间，其他问题极有可能是语句不合理引起的。
主要推理如下：
当一些反复执行的SQL语句效率过低时，首先会造成高速缓存不够用，随之引起较大的I/O；而频繁的I/O势必会消耗大量的CPU。
因此整个系统的瓶颈极有可能是这三个语句引起的。
测试过程中棘手的性能问题
这两次测试结果还有一个奇怪的现象：
一方面事务响应时间较快，另一方面却有大量的事务没有响应。
仅根据目前的测试结果还看不出直接原因。
但这也很可能是前面的三个SQL语句引起的：
因为这种现象很像用户直接收到不能访问的通知，所以不再等待服务器的结果反馈，在客户端的表现就是页面无法打开。
这种现象很有可能是耗资源的SQL语句瞬间霸占了全部CPU资源，导致数据库拒绝服务。
当调整了SQL语句再次进行测试时，这种现象消失，证明推理是正确的。
再借助Analysis打开图5-14的“事务平均响应时间图”和图5-15的“建立第一个缓冲的时间分解图”，可以得出以下结论：
（1）事务平均响应时间稳定，说明本次测试的性能问题主要在程序自身。
如果是服务器存在问题，则长时间的压力测试会导致响应时间越来越长；
（2）“建立第一个缓冲的时间”主要消耗在服务器上，说明对用户请求的处理方式不合理。
图5-14和图5-15进一步证明了SQL语句可能就是造成系统瓶颈的根本原因。
图5-14 事务平均响应时间图
图5-15 建立第一个缓冲的时间分解图
因此，下一步应该先对SQL语句进行优化，然后对系统进行测试。
SQL语句调整后的测试 开发人员优化了SQL语句后，并对900个用户进行并发、持续1.5小时的压力测试，测试结果如图5-16所示。
从图中可以看出，调整后系统的性能非常稳定，所有的用户均可以成功打开“视频播放页面”。
图5-16 SQL语句调整后的测试
再借助Analysis打开图5-17所示的事务平均响应时间图，可以看到整个测试过程“打开播放页面”的平均响应时间成平滑水平线，系统的性能非常稳定。
由此可以得出结论：
调整SQL语句的策略是正确的。
图5-17 调整后的事务平均响应时间图
与图5-11和图5-12的测试结果相比，有个细节在分析的时候应该注意到，那就是事务评价响应时间变长了！
前面两次测试结果的事务平均响应时间是1秒，而本次则是39秒。
那么，哪次的测试结果更合理呢？
根据常理，本次测试用的是普通的PC服务器，900个并发用户用1秒的响应时间显然不合理，39秒才符合实际情况。
1秒的事务平均响应时间只是一种假像，是系统存在性能问题造成的。
对于“播放页面”的性能，在图5-16中有稳定表现，可以认为测试过关！
到目前为止，本次性能测试的思路是正确的，可以推广到其他功能点的独立或组合性能测试中。
3.性能调优方案
最后，对整个上线系统提出了以下调优方案：
系统配置方面
（1）把Oracle的运行模式调成“共享服务器模式”；
（2）增加了分配给Oracle的内存：
把内存调整成系统内存的55%；
（3）增加共享池（SHARED_POOL）和缓冲区高速缓存（DB_CACHE）的大小；
（4）对数据库表和查询相关的字段建立索引；
应用程序方面
（1）用优化后的程序来替换原有程序；
（2）采用页面缓存技术来提高用户访问速度，同时减缓对数据库的压力；
线上的性能测试验证
按照调优方案对线上系统进行调整后，接下来的工作就是和客户一起验证系统的综合性能表现。
线上测试与实验室测试不同，不能影响用户的正常使用——不但不能产生垃圾数据，更不能把服务器压垮。
在前面的项目背景中，提到过本系统的设计目标是满足每天150万的PV（页面浏览量），因此，线上测试主要是为了评估服务器能够处理的浏览量。
同时，为了保证服务器的稳定运行，在真实线上环境只模拟了500个并发用户。
下面是对线上系统首页的测试结果摘要，主要测试了动态页面无缓存、静态页面缓存方式两种情况：
1.页面无缓存、500用户并发
测试场景持续执行时间：
6分钟
运行的最大用户数：
1000个
测试内容：
打开任意视频进行播放
事务平均响应时间如图5-18所示。
图5-18 事务平均响应时间
事务响应时间的详细情况如表5-2所示。
表5-2 事务响应时间（秒）
最小值
平均值
最大值
0.622
6.247
12.338
CPU利用率如图5-19所示。
图5-19 CPU利用率
其中服务器CPU利用率（％）的详细情况如表5-3所示。
表5-3 服务器CPU利用率
最小值
平均值
最大值
Oracle服务器
0.0
82.723
95.703
Web服务器
4.688
67.543
95.833
每秒播放页面下载数如图5-20所示。
图5-20 每秒页面下载数
每秒播放页面下载数的详细表情况如表5-4所示。
表5-
升级会员 