学会看懂LoadRunner分析报表.docxVIP

学会看懂LoadRunner分析报表图表分析：　一、 Web Page Breakdown　DNS 解析时间： 显示使用最近的 DNS 服务器将 DNS 名称解析为 IP 地址所需的时间； DNS 查找度量是指示 DNS 解析问题或 DNS 服务器问题的一个很好的指示器；　Connect 时间： 显示与包含指定 URL 的 Web 服务器建立初始连接所需的时间； Connect 度量是一个很好的网络问题指示器；它还可表明服务器是否对请求做出响应；　First buffer 时间： 显示从初始 HTTP 请求到成功收回来自 WEB 服务器的第一次缓冲时为止所经过的时间； First buffer 度量是很好的 Web 服务器延迟和网络滞后指示器；　SSL Handshaking time ： 显示建立 SSL 连接所用的时间　Receive Time ： 显示从服务器收到最后一个字节并完成下载之前经过的时间；接收度量是很好的网络质量指示器；　FTP 验证时间： 显示验证客户端所用的时间。　Client Time ： 显示因浏览器思考时间或javascript:;其他与客户端有关的延迟而使客户机上的请求发生延迟时，所经过的时间。　Error 时间： 显示从发出 HTTP 请求到返回错误消息这期间所经过的平均时间　二、 关于 TPS （ Transactions per Second ）： 每秒处理事务数　这个值可以说明系统在特定的负载情况下，每秒可以处理多少个客户端请求，这是一个衡量服务器端性能的重要指标，相信各位在进行javascript:;性能测试的时候经常会用到这个指标。但是一直以来我都有一个疑问，到底这个值是怎么算出来的。既然是每秒事务数，那算法自然是“事务数 / 时间”。事务数很好理解，执行了多少就是多少，关键是这个时间。是整个场景执行的时间，还是仅仅是在服务器端执行的时间？因为我们知道，这两个时间肯定是有区别的，前者还包括 thinktime 的时间、 pacing 的时间以及在网络上耗费的时间等等。　为了弄明白这个问题，我今天特地查了一下帮助文档，看到上面是这么说的：“每秒事务数图显示在场景或会话步骤运行的每一秒中，每个事务通过、失败以及停止的次数。”如果按照这句话去理解，那么上面那个问题的答案应该是后者，也就是说，在 Transaactions per Second 这张图中， LoadRunner 是针对场景运行过程中的每一个时间点取样一次，显示在这个时间点上每个事务的通过、失败以及停止的个数。　另外，我还在 Analysis 里面找了一下，发现图表的时间显示粒度也是可以设置的。具体方法为：在图表上点击右键 - 选择“ Set Granularity ”或者直接按 Ctrl+G 。我试着把时间粒度调成以毫秒为单位，结果 LoadRunner 提示当前不支持以毫秒为显示粒度，由此我推断 LoadRunner 对于 Transactions per Second 这张图，最小的取样粒度为 1 秒。　三、 Transaction Response Time事务响应时间（百分比）图　这个图显示的是事务响应时间范围的分布情况。在场景的执行中，每个定义的事务可能会不止被处理一次（因为设置了持续时间或者迭代次数）， LoadRunner 会为每个事务实例的处理分别记录响应时间。在 Summary Report 中， LoadRunner 会针对每个事务的响应时间数据集合，分别取它的最大值、最小值和平均值，通常我们会关注响应时间的平均值。然而很多时候，单单是平均响应时间可能是不够的，因为一旦最大值和最小值出现较大的偏差，即便平均响应时间处在可以接受的范围内，但并不意味着整个系统的性能就是可以接受的，我们有必要再借助javascript:;其它的分析报表来进一步分析，此时事务响应时间（百分比）图就派上用场了。　事务响应时间（百分比）给出的是每个事务的响应时间按百分比的分布情况，它告诉我们本次测试有多少个事务的平均响应时间是落在我们可以接受的时间范围之内。如果最大响应时间非常长，但是绝大多数事务（通常情况下以 95% 为参考）的响应时间具有可以接受的响应时间，则我们认为整个系统的性能还是可以接受的。　注意： Analysis 将对每个可用事务百分比的事务响应时间取近似值。因此 Y 轴的值可能并不准确。　四、 Transaction Response Time事务响应时间（负载下）图　这个图显示的是事务响应时间随着场景中虚拟用户的逐渐增长的变化趋势图，该图可以帮助我们查看 Vuser 负载对性能问题的影响。当我们需要了解某个事务的响应时间随着虚拟用户的增加而产生的变化时，可以通过在控制台中设置一个渐变负载的场景的方式来实现。例如每 5