LoadRunner笔记（二）

 

第一章：

 java tools完成j2ee的自动化，但作为开发人员应该明白其基本原理
 web service需要多次在xml间的转换，如果从性能上考虑，不可多用
 性能：1）支持人员：响应时间  2）管理员: 环境配置 3）database programer：SQL执行效率 4）database administrator：数据库环境
 性能管理:
  1. 架构： 架构必须考虑到对象的生命周期和使用方法，如什么时候使用模式，entity bean等。
  2. 要监控的是：资源使用情况，响应时间随着时间和登录用户的变化情况。
  2. 管理员责任： cluster的配置，

html 和url 两种协议的区别：
1 基于浏览器的应用程序推荐使用 HTML-based Script
2 不是基于浏览器的应用程序推荐使用 URL-based Script。
3 如果基于浏览器的应用程序中包含了 JavaScript 并且该脚本向服务器产生 了请求，比如 DataGrid 的分页按钮等，也要使用 URL-based  方式录制
4 基于浏览器的应用程序中使用了 HTTPS 安全协议，使用 URL-based 方式 录制

参数的类型：
 Load  Generator  Name ：在实际运行中，LoadRunner   使用该虚拟用户所在 Load Generator 的机器名来代替。
 Iteration  Number ：在实际运行中，LoadRunner  使用该测试脚本当前循环的次数来 代替。
 Vuser  ID：设置比较简单。在实际运行中，LoadRunner 使用该虚拟用户的 ID 来代替，
 数据库： file类型的data wizard. Sequential：按照顺序一行行的读取。每一个虚拟用户都会按照相同的顺序读取
 Unique ：唯一的数。注意 ：使用该类型必须注意数据表有足够多的数 。比如 Controller 中设定 20 个虚拟用户进行 5 次循环，那么编号为 1 的虚拟用户取前 5 个数，编号为 2 的虚拟用户取 6-10 的数，依次类推，这样数据表中至少要有 100 个数据，否则 Controller 运行过程中会返回一个错误。
Runtime-setting：
 NetWork设置带宽格式：带宽越大，给 Web 服务器造成的压力就越大。
 Preference：启动image和text检查。不重要资源出错作为warning
 ContentCheck：设置自定义的错误页面

第二章

创建运行场景：

0.保存Scenario:
      Scenario————》save load generator
1.设置scheduler:
      duration代表加载完用户后场景运行的时间
2.设置结果保存路径：

 result-->result settings: 所有结果的保存根目录。
Goal—Oriented Scenario ： 在测试计划中，一般都包括性能测试要达到的目标。选择该项后，LoadRunner  基于这个目标，自动为你创建一个场景。在场景中，我 们只要定义好我们的目标即可。
 Virtual Users Goal：需要测试多少人可以同时运行 Web 应用
 如果想测试 Web Server 的真正实力，推荐定义目标类型为：Hits per Second、Pages per Minute 或者 Trans actions  per  Second，这些类型都需要指定一个虚拟用户的最小值和最大值 的范围。
Controller  试图使用最少的虚拟用户来达到定义的目标。如果使用最少的用户，不能达 到目标，Controller  增加用户数，直到定义的最大值。如果使用了最多的虚拟用户数，定义
的目标还没有实现，那么需要增加最大用户数，重新执行场景。
 如果想知道在多少用户并发访问网站时，事务的响应时间达到性能指标说明书中规定响 应时间的最大值，那么推荐使用 Transactions Response Time 类型。

3. Percentage Mode 和 Vusers Group 之间互相转化:

      Scenario-->convert ...

优化 Controller 和 Load Generators 计算机
 如果控制机（Controller machine）和 Load Generators 计算机运行的都是 Windows2000， 那么下面两个简单的技巧可以提高性能
 在 Load  Generators 计算机上，依次进入“控制面板”——“系统”——选择“高级” 标签页，点“性能选项”按钮，选择优化“后台服务”选项，这样可以提高性能，从而 可以在每个 Load Generators 上运行更多的虚拟用户
 在 Controller 计算机上，按照以上的步骤，进入“性能选项”窗口，不过这里选择优化 “应用程序”

理解各种类型

如果你定义的类型是 Pages per Minute、Hits/Transactions per Second，Controller 首先用 最小用户数除以定义的目标，得到一个值，然后确定每个用户应该达到的 hits/transactions 或者 pages per minute，然后 controller 开始按照以下的策略加载用户：
 如果选择的是自动的加载虚拟用户，LoadRunner 会首先加载 50 个用户。如果定义的最 大用户数小于 50，LoadRunner 就会一次加载所有的虚拟用户。
 如果选择的是在场景运行一段时间后达到目标，LoadRunner  就会尝试在定义的这段时 间内达到目标，根据时间限制和计算出的每个用户的 hits、transactions  或者 pages，
LoadRunner 确定第一批加载多少用户。
 如果选择的是按照一定的阶段达到目标（也就是先在 x 长时间内达到 y pages/hits，然后 再达到下一个目标），LoadRunner 计算每个用户应该达到的数字后，再确定第一批加载 多少用户。
每加载一批用户后，LoadRunner  会判断是否达到这批用户的目标。如果这批用户的目
标没有达到，LoadRunner  重新计算每一个用户应该达到的目标数字后，重新调整下一批加 载用户的数量。默认情况下，LoadRunner 每两分钟加载一批用户。
如果 Controller 加载了最多数量的用户还没有达到预定的目标，LoadRunner 会重新计算
每个用户的目标，然后同时运行最大数量的用户，尝试达到预定的目标。 如果出现以下情况，Pages  per  Minute、Hits/Transactions  per  Second 类型的场景会置于
“Failed”状态：
 Controller 使用了指定的最大数量的用户，并且两次都没有达到目标
 所有的用户运行都失败
 没有足够的 Load Generators 机器（现有的机器已经超载运行的情况下）
 Controller 增加了几批用户后，pages per minute 或者 hits/transactions per second 没有 增加
 Controlller 加载第一批用户后，定义的目标没有被捕捉到
分析及监视场景（参考原文档）

 Memory：主要检查应用程序是否存在内存泄漏。如果发生了内存泄漏，Process \Private Bytes计数器和 Process \Working Set 计数器的值往往会升高，同时 Available Bytes 的值会降低。
内存泄漏应该通过一个长时间的，用来研究分析当所有内存都耗尽时，应用程序反应情况的 测试来检验。
  Available MBytes: 至少有百分之10
  Page/sec推荐0-20，大于80可能是内存短缺
 Processr：
  System/Processor Queue Length: 处理队列中的线程数，要小于2，否则为线程堵塞。
8. 分析实时监视图表可以再看

如果Throughput图是平的，则说明网络带宽是瓶颈（比较接受到的数据和网络带宽）

分析结果

 1）看Transaction Performance Summary确定哪个事务的响应时间超过标准
 2）看Average Transaction Response Time看该事务响应时间的变化过程
 3）选择“Web Page Breakdown for login”分解事务曲线，各个时间的含义参考原文件
 4）看“Download Time Breakdown”的下载时间和组件大小，更详细的信息参考“Download  Component  Size
Graph”。利用该图可以看出该页面各种组件的大小所占的比例关系。 同样，要看各个组件下载时间的更详细的信息，可以参考“Page Component Breakdown”。
 5）为了确认问题缘由到底是服务器还是网络，选择“Time to First Buffer Breakdown”，可以看
出 Server 时间比 network 时间要高的多，从而确定问题是服务器引起的。然后我们就可以参考 Web  Server 的相关图表，来确定问题是由服务器的哪个部分引起。
9.1 确定WebServer的问题
 最常见的数据库问题是效率比较低的索引设计，数据碎片太多，过时的统计表以及不完 善的应用程序设计。
 在 20%的压力测试中，发现 Web Server 和 Web 应用程序是性能的瓶颈。这些瓶颈主要 是由于服务器配置不当和资源不足。比如，编程比较差的代码以及形成的 DLL 能够使用所 有的计算机处理器资源，导致了 CPU 的瓶颈。同样，对内存的操作不当和管理不善也很容 易造成内存的瓶颈，所以我们建议在排除其他可能的因素外，首先检查 CPU 和物理内存。
9.2 比较每次运行的结果
 一般情况下，我们进行性能测试的步骤是这样：
1  首先进行一次性能测试，记录下结果，然后分析结果，提出改进的建议
2  开发人员根据建议对代码或者服务器的配置进行修改
3  测试人员在相同的条件下进行第二轮测试
4  测试人员对两轮测试结果比较，确定开发人员修改的结果是否有效
Analysis的菜单： File--》Cross With Results;
9.3 合并图表
 在分析结果的过程中，我们可能需要以“运 行的用户数”作为横坐标，来比较结果。

常见问题

 在 VuGen 中运行良好的脚本，到 Controller 中运行却出问题。 这种问题可能会遇到。为了确定问题出在 Controller 中的场景，而不是脚本的问题，
你应该在所有的 Load Generators 机器上使用 VuGen 运行测试脚本，确保都能够运
行正确。
 添加了 Windows Resources  计数器后，却看不到实时的数据。解决方法：要得到监视的数据，必须要在被监视的服务器（Web Server）上获得管
理员权限。最简单的方法是在“网络邻居”中以 administrator 身份登陆 Web Server。 当然使用下面的控制台命令也可以：net use  \\<机器名>  然后登陆用户名和密码即 可。（登陆的用户名必须具有管理员权限）

每秒点击率显示在网站服务器上随着时间推移的点击数量，你可以将它与事务响应时间图表和吞吐率对比来查看点击是如何影响事务的执行的。
完美的吞吐量应该是随着每秒点击率的增加而增加，这种增加是建立在带宽足够处理用户提出的所有请求的基础上的。
如果点击的次数增加而吞吐量恒定或减少，就说明服务器无法执行增加的请求（每秒点击率），结果就是事务反应时间的增加。
我们知道在前25分钟，加载250个用户会使其到达峰值，由此，预期的每秒点击率的增长和吞吐量的减少说明了服务器的负载已经达到了它的最大值。我们可以预计事务的处理时间和每秒可能发生的错误也会在25分钟前后达到峰值。
事务处理响应时间增加的最通常的原因是运行的用户增加
你应该先对比运行的虚拟用户数量与每秒事务图，以核实一次虚拟用户的增加是否导致每秒点击率、事务响应时间和吞吐量的增加，将这些统计数据放到一起会帮助你找出问题发生的主要原因
分析Transaction summary你可以发现事务成功/失败的比率，并确定哪个事务看起来需要更多注意。单一事务的大量失败表明在测试场景中有某类型的问题在一个时刻出现了，出现这种问题的原因可能是某个服务器或页面的问题。

我的使用：

Duration代表加载完成后运行的时间（应该是执行完Init以后吧）
 单个Load generator的上限是5000
 当运行controller时，先设置result为每一个Senario生成目录。Scenario可以点击另存为为下一场景准备，则monitor等不需要重新配置。
三个重要的东西：
 0.设计测试目标：内容有三种，1）正常场景 2）峰值测试 3）以目标为导向的极限测试；格式为 1）时间区间内，多少任务完毕 2） 时间区间内，每N分钟一个操作。 3）响应时间条件下，最多支持X秒X个任务
 1.设计测试场景，基本上有两种1）多长时间完成多少用户；2）目标：特定目标下的用户数 3） 每N分钟多少用户
 2.脚本的录制和修改
 3.添加监视图表
 4.分析程序