以上的数据请求可以从数据缓冲区中获得所需数据。 Batch Requests/sec 每秒收的 Transact-SQL 命令批数。这一统计信息受所有约束（ 如I/O、用户数、高速缓存大小、请求I/O、用户数、高速缓存大小、请求的复杂程度等） 影响。批请求数值 高意味着吞吐量很好。 每秒被缓冲区管理 器的惰性写入器写入的缓冲区数。惰性写入器是一 个系统进程， 其主要任务是刷新成批的老化的脏缓冲区（ 指包含更改 的缓冲区， 这些更改必须写回磁盘， 才能使该缓冲区由其它页重新使 用）， 并使之可由用户进程使用。惰性写入器消除了为创建可用缓冲区而频繁执行检查点的需要。 每秒发出的物理数 SQLServer SQL Statistics SQL Server: Buffer Manager Lazy Writes/sec SQL Server: Page Reads/sec Buffer Manager 据库页读取数。这一统计信息显示的是在所有数据 库间的物理页读取总数。由于物理I/O 的开销大， 可以通过使用更大 的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法， 使开销减到最小。 每秒为数据库启动 的事务数 SQL Server:Databases Transactions/sec 这里针对SQL Server2000， 而且只是列出比较关键的几个。更加详细的信息可以参考SQL Server 的联机文档。
如果要监视的两台计算机在同一个局域网络内， 建议不要使用Network Delay Monitor。
因为在同一局域网内，Network Delay 会非常的小， 网络监视器会有足够的时间在每秒钟内发送成百上千的请求， 这样会导致源计算机（source machine） 的CPU 和内存超负荷工作。
默认情况下“Enable display of network nodes by DNS names” 选择是没有选中的， 因为
选中它会明显的降低该监视器的速度。
分析实时监视图表
这一章仅仅介绍几个最重要的图表。
Q1 事务响应时间是否在可接受的时间内？ 哪个事务用的时间最长？
看Transaction Response Time 图， 可以判断每个事务完成用的时间， 从而可以判断出那个事务用的时间最长， 那些事务用的时间超出预定的可接受时间。 Q2 网络带宽是否足够?
“Throughput”图显示在场景运行期间的每一秒钟， 从Web Server 上接受到的数据量的值。
拿这个值和网络带宽比较， 可以确定目前的网络带宽是否是瓶颈。
如果该图的曲线随着用户数的增加， 没有随着增加， 而是呈比较平的直线， 说明目前的
网络速度不能够满足目前的系统流量。 Q3 硬件和操作系统能否处理高负载?
“Windows Resources” 图实时地显示了Web Server 系统资源的使用情况。利用该图提供的数据， 可以把瓶颈定位到特定机器的某个部件。
经常遇到的问题
脚本的问题
在使用VuGen 中经常会遇到的问题。
controller的问题
在使用Controller 中经常会遇到的问题。
1. 在添加完Load Generators 机器时， 连接老是失败； 添加的机器明明已经安装了
loadrunner， 并且网络通讯正常。
解决方法： 在安装loadrunner 的第七步骤， 应该选择第2 项， 如果选择了第一项，
就会有这种问题。重新安装一下即可。
2. 在VuGen 中运行良好的脚本， 到Controller 中运行却出问题。
这种问题可能会遇到。为了确定问题出在Controller 中的场景，而不是脚本的问题，
你应该在所有的Load Generators 机器上使用VuGen 运行测试脚本， 确保都能够运
行正确。因为VuGen 和Controller 运行的机制不一样。在VuGen 中运行时使用的
是完整的浏览器， 而在Controller 中运行时使用的只是浏览器的基本的部分。
计数器的问题
在使用性能计数器中经常会遇到的问题。
1. 添加了Windows Resources 计数器后， 却看不到实时的数据。
解决方法： 要得到监视的数据， 必须要在被监视的服务器（Web Server） 上获得管
理员权限。最简单的方法是在“ 网络邻居”中以administrator 身份登陆Web Server。
当然使用下面的控制台命令也可以：net use \\\\< 机器名> 然后登陆用户名和密码即
可。（登陆的用户名必须具有管理员权限） 2. 添加了一些默认的性能计数器后， 出现了错误。
解决方法： 可能是一些LoadRunner 默认的计数器在WebServer 上已经不存在的原
因， 尤其是数据库的计数器方面。简单的解决方法， 就是删除有问题的计数器， 添
加比较接近的计数器（ 可能需要参考Windows 帮助或者数据库的帮助）
结果分析
根据不同的场景设计，配置脚本后进行测试得到如下结果 测试环境
LMM:
CPU：4x2.7G RAM:4G Websphere 5.0 + IBM Http Server 线程池：100 JDBC连接池：100 会话超时：30分钟 DS:
CPU：4x2.2 RAM:4G Websphere 5.0 + IBM Http Server 线程池：100 JDBC连接池：100 会话超时：30分钟
DB&LDAP:
CPU：2x2.2G RAM:4G Oralce 8.1.7 + LDAP
测试工具：Load Runner 7.8
用户数据：用户名test1 – test100； 口令与用户名相同。
测试用例1 测试场景描述
用户登录的lmm模块，总共登陆24个用户，所有用户都同时并发操作。