(利用loadrunner分析场景、监视图表.docxVIP

7 分析以及监视场景在运行过程中，可以监视各个服务器的运行情况（DataBase Server、Web Server 等）。监视场景通过添加性能计数器来实现。这一章非常的重要，确定系统瓶颈全靠它了。下面重点讲讲需要添加那些计数器，以及那些计数器代表什么意思。由于Win2000 Professional、Server 以及Advanced Server 提供的计数器不完全相同，这里我们讨论将以Server 为基准。监视场景需要在Run 视图中设置然后，出现添加计数器的对话框其他的操作就和控制面板“性能”中添加性能计数器的操作一样，这里不再详细说明。本章主要说明一下各个系统计数器的含义（数据库的计数器不做重点，只是拿SQLServer2000 作为例子进行说明。因为数据库各个版本之间差异比较大，请参考您使用的数据库系统的帮助）。8 分析实时监视图表这一章仅仅介绍几个最重要的图表。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 事务的响应时间并不是一直都比较高，只是随着用户数的增加，响应时间才明显增加的。为了定位问题，明白为什么login 事务的响应时间比较长，现在我们要分解login 事务，分析该页面上每一个元素的性能。在上图中，选择要分解的事务曲线，然后点鼠标右键，选择“Web Page Breakdown for login”9.2 分解页面通过分解页面可以得到：比较大的响应时间到底是页面的哪个组件引起的？问题出在服务器上还是网络传输上。这里为了解说各个时间（比如：DNS 解析时间、连接时间、接受时间等）下面简单说一下浏览器从发送一个请求到最后显示的全过程。1. 浏览器向Web Server 发送请求，一般情况下，该请求首先发送到DNS Server 把DNS名字解析成IP 地址。解析的过程的时间就是。这个度量时间可以确定DNS 服务器或者DNS 服务器的配置是否有问题。如果DNS Server 运行情况比较好，该值会比较小。2. 解析出Web Server 的IP 地址后，请求被送到了Web Server，然后浏览器和WebServer 之间需要建立一个初始化连接，建立该连接的过程就是。这个度量时间可以简单的判断网络情况，也可以判断Web Server 是否能够响应这个请求。如果正常，该值会比较小。3. 建立连接后，从Web Server 发出第一个数据包，经过网络传输到客户端，浏览器成功接受到第一字节的时间就是。这个度量时间不仅可以表示WebServer 的延迟时间，还可以表示出网络的反应时间。4. 从浏览器接受到第一个字节起，直到成功收到最后一个字节，下载完成止，这段时间就是。这个度量时间可以判断网络的质量（可以用size/time 比来计算接受速率）其他的时间还有SSL Handshaking（SSL 握手协议，用到该协议的页面比较少）、ClientTime（请求在客户端浏览器延迟的时间，可能是由于客户端浏览器的think time 或者客户端其他方面引起的延迟）、Error Time（从发送了一个HTTP 请求，到Web Server 发送