LoadRunner分析实时监视图表.docVIP

分析实时监视图表 Q1 事务响应时间是否在可接受的时间内？哪个事务用的时间最长？ 看 Transaction Response Time 图，可以判断每个事务完成用的时间，从而可以判断出那个事务用的时间最长，那些事务用的时间超出预定的可接受时间。 下图可以看出，随着用户数的不断增加，login 事务的响应时间增长的最快！ Q2 网络带宽是否足够? “Throughput”图显示在场景运行期间的每一秒钟，从Web Server 上接受到的数据量的值。 拿这个值和网络带宽比较，可以确定目前的网络带宽是否是瓶颈。 如果该图的曲线随着用户数的增加，没有随着增加，而是呈比较平的直线，说明目前的 网络速度不能够满足目前的系统流量。 Q3 硬件和操作系统能否处理高负载? “Windows Resources”图实时地显示了Web Server 系统资源的使用情况。利用该图提供的 数据，可以把瓶颈定位到特定机器的某个部件。 9 利用Analysis 分析结果 场景运行结束后，需要使用Analysis 组件分析结果。Analysis 组件可以在“开始程序” 菜单中启动，也可以在Controller 中启动。 由于我本人对怎样分析结果最有效没有进行比较多的实践，所以这里只能按照常规的方 法进行简单介绍。 注意：这里介绍的分析方法只适用于Web 测试。 9.1 分析事务的响应时间 第一步，看“Transaction Performance Summary”图，确认那个事务的响应时间比较大， 超出了我们的标准。看下图，login 事务的平均响应时间最长。 然后我们再看“Average Transaction Response Time”，观察login 在整个场景运行中每一 秒的情况。从图中可以看出，login 事务的响应时间并不是一直都比较高，只是随着用户数 的增加，响应时间才明显增加的。 然后我们再看“Average Transaction Response Time”，观察login 在整个场景运行中每一 秒的情况。从图中可以看出，login 事务的响应时间并不是一直都比较高，只是随着用户数 的增加，响应时间才明显增加的。 为了定位问题，明白为什么login 事务的响应时间比较长，现在我们要分解login 事务， 分析该页面上每一个元素的性能。在上图中，选择要分解的事务曲线，然后点鼠标右键，选 择“Web Page Breakdown for login” 性能测试（并发负载压力）测试分析 (2007-04-27 10:33:45) 转载 ? 分类：LoadRunner ?分析原则：????#8226;?具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）????#8226;?查找瓶颈时按以下顺序，由易到难。????服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）????注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。????#8226;?分段排除法?很有效分析的信息来源：????#8226;1?根据场景运行过程中的错误提示信息????#8226;2?根据测试结果收集到的监控指标数据一．错误提示分析分析实例：1?#8226;Error:?Failed?to?connect?to?server?10.10.10.30:8080:?[10060]?Connection??#8226;Error:?timed?out?Error:?Server?10.10.10.30?has?shut?down?the?connection?prematurely??分析：#8226;A、应用服务死掉。???（小用户时：程序上的问题。程序上处理数据库的问题）#8226;B、应用服务没有死???（应用服务参数设置问题）????例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection?refused消息，说明应提高该值，每次增加25％#8226;C、数据库的连接???(1、在应用服务的性能参数可能太小了?2、数据库启动的最大连接数（跟硬件的内存有关）)2??Error:?Page?download?timeout?(120?seconds)?has?expired?分析：