LoadRunner分析实时监视图表

《LoadRunner分析实时监视图表》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、8分析实时监视图表这一章仅仅介绍几个最重要的图表。Q1事务响应时间是否在可接受的时间内？哪个事务用的时间最长？看TransactionResponseTime图，可以判断每个事务完成用的时间，从而可以判断出那个事务用的时间最长，那些事务用的时间超出预定的可接受时间。下图可以看出，随着用户数的不断增加，login事务的响应时间增长的最快！Q2网络带宽是否足够?“Throughput”图显示在场景运行期间的每一秒钟，从WebServer上接受到的数据量的值。拿这个值和网络带宽比较，可以确定目前的网络带宽是否是瓶颈。如果该图的曲线随着用户数的增加，没有随着增加，而是呈比较平的直线

2、，说明目前的网络速度不能够满足目前的系统流量。Q3硬件和操作系统能否处理高负载?“WindowsResources”图实时地显示了WebServer系统资源的使用情况。利用该图提供的数据，可以把瓶颈定位到特定机器的某个部件。9利用Analysis分析结果场景运行结束后，需要使用Analysis组件分析结果。Analysis组件可以在“开始程序”菜单中启动，也可以在Controller中启动。由于我本人对怎样分析结果最有效没有进行比较多的实践，所以这里只能按照常规的方法进行简单介绍。注意：这里介绍的分析方法只适用于Web测试。9.1分析事务的响应时间第一步，看“Transac

3、tionPerformanceSummary”图，确认那个事务的响应时间比较大，超出了我们的标准。看下图，login事务的平均响应时间最长。然后我们再看“AverageTransactionResponseTime”，观察login在整个场景运行中每一秒的情况。从图中可以看出，login事务的响应时间并不是一直都比较高，只是随着用户数的增加，响应时间才明显增加的。然后我们再看“AverageTransactionResponseTime”，观察login在整个场景运行中每一秒的情况。从图中可以看出，login事务的响应时间并不是一直都比较高，只是随着用户数的增加，响应时间才

4、明显增加的。为了定位问题，明白为什么login事务的响应时间比较长，现在我们要分解login事务，分析该页面上每一个元素的性能。在上图中，选择要分解的事务曲线，然后点鼠标右键，选择“WebPageBreakdownforlogin”性能测试（并发负载压力）测试分析(2007-04-2710:33:45)转载 分类：LoadRunner 分析原则：    • 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）    • 查找瓶颈时按以下顺序，由易到难。    服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统

5、瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）    注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。    • 分段排除法 很有效分析的信息来源：    •1 根据场景运行过程中的错误提示信息    •2 根据测试结果收集到的监控指标数据一．错误提示分析分析实例：1 •Error: Failed to connect 

6、to server "10.10.10.30:8080": [10060] Connection  •Error: timed out Error: Server "10.10.10.30" has shut down the connection prematurely  分析：•A、应用服务死掉。   （小用户时：程序上的问题。程序上处理数据库的问题）•B、应用服务没有死   （应用服务参数设置问题）    例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的

7、AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％•C、数据库的连接   (1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)2  Error: Page download timeout (120 seconds) has expired 分析：可能是以下原因造成•A、应用服务参数设置太大导致服务器的瓶颈•B、页面中图片太多•C、在程序处理表的时候检查字段