利用loadrunner分析场景监视图表.docVIP

7 分析以及监视场景 在运行过程中，可以监视各个服务器的运行情况（DataBase Server、Web Server 等）。 监视场景通过添加性能计数器来实现。这一章非常的重要，确定系统瓶颈全靠它了。 下面重点讲讲需要添加那些计数器，以及那些计数器代表什么意思。 由于 Win2000 Professional、Server 以及Advanced Server 提供的计数器不完全相同，这 里我们讨论将以Server 为基准。 监视场景需要在 Run 视图中设置 然后，出现添加计数器的对话框 其他的操作就和控制面板“性能”中添加性能计数器的操作一样，这里不再详细说明。 本章主要说明一下各个系统计数器的含义（数据库的计数器不做重点，只是拿SQL Server2000 作为例子进行说明。因为数据库各个版本之间差异比较大，请参考您使用的数据 库系统的帮助）。 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，然后浏览器和Web Server 之间需要建立一个初始化连接，建立该连接的过程就是。这个 度量时间可以简单的判断网络情况，也可以判断Web Server 是否能够响应这个请 求。如果正常，该值会比较小。 3. 建立连接后，从Web Server 发出第一个数据包，经过网络传输到客户端，浏览器 成功接受到第一字节的时间就是。这个度量时间不仅可以表示Web Server 的延迟时间，还可以表示出网络的反应时间。 4. 从浏览器接受到第一个字节起，直到成功收到最后一个字节，下载完成止，这段时 间就是。这个度量时间可以判断网络的质量（可以用size/time 比来计算 接受速率） 其他的时间还有 SSL Handshaking（SSL 握手协议，用到该协议的页面比较少）、Client Time（请求在客户端浏览器延迟的时间，可能