度会出如果这两个值太大， 那么需要重现“服务器太忙”错误 5.6 SQL Server
这里针对SQL Server2000， 而且只是列出比较关键的几个。更加详细的信息可以参考SQL Server 的联机文档。 SQL Server: Buffer Manager Page Reads/sec 每秒发出的物理数据库页读取数。这一统计信息显示的是在所有数据 库间的物理页读取总数。由于物理I/O 的开销大， 可以通过使用更大 的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法， 使开销减到最小。 每秒为数据库启动的事务数 SQL Server:Databases Transactions/sec 这里针对SQL Server2000， 而且只是列出比较关键的几个。更加详细的信息可以参考SQL Server 的联机文档。
5.7 Network Delay
如果要监视的两台计算机在同一个局域网络内， 建议不要使用Network Delay Monitor。 因为在同一局域网内，Network Delay 会非常的小， 网络监视器会有足够的时间在每秒钟内发送成百上千的请求， 这样会导致源计算机（source machine） 的CPU 和内存超负荷工作。
默认情况下“Enable display of network nodes by DNS names” 选择是没有选中的，
因为
选中它会明显的降低该监视器的速度。
6 分析实时监视图表
这一章仅仅介绍几个最重要的图表。
Q1 事务响应时间是否在可接受的时间内？ 哪个事务用的时间最长？
看Transaction Response Time 图， 可以判断每个事务完成用的时间， 从而可以判断出那个事务用的时间最长， 那些事务用的时间超出预定的可接受时间。 Q2 网络带宽是否足够?
“Throughput”图显示在场景运行期间的每一秒钟， 从Web Server 上接受到的数据量的值。
拿这个值和网络带宽比较， 可以确定目前的网络带宽是否是瓶颈。
如果该图的曲线随着用户数的增加， 没有随着增加， 而是呈比较平的直线， 说明目前的 网络速度不能够满足目前的系统流量。 Q3 硬件和操作系统能否处理高负载?
“Windows Resources” 图实时地显示了Web Server 系统资源的使用情况。利用该图提供的数据， 可以把瓶颈定位到特定机器的某个部件。
7 分析原则
● 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）
● 查找瓶颈时按以下顺序，由易到难。
服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）
注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。
● 分段排除法 很有效 分析的信息来源：
● 根据场景运行过程中的错误提示信息 ● 根据测试结果收集到的监控指标数据 7.1、错误提示分析 分析实例：
1、Error: Failed to connect toserver“payment.baihe.com″: [10060] Connection Error: timed out Error:Server“user.baihe.com″has shut down the connection prematurely 分析：
A、应用服务死掉。
（小用户时：程序上的问题。程序上处理数据库的问题） B、应用服务没有死 （应用服务参数设置问题）
例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％ C、数据库的连接
在应用服务的性能参数可能太小了或者数据库启动的最大连接数（跟硬件的内存有关） 2、Error: Page download timeout (120 seconds) has expired 分析：可能是以下原因造成
A、应用服务参数设置太大导致服务器的瓶颈 B、页面中图片太多
C、在程序处理表的时候检查字段太大多 7.2、监控指标数据分析 1、最大并发用户数
应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大
并发用户数。
在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。 2、业务操作响应时间
● 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
● 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？
● 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题
2-5-10原则：简单说，就是当用户能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；当用户在5-10秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过10秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个Web站点，或者发起第二次请求。
8．测试结果
配置脚本后进行测试得到如下结果 总报告reports
用户数Running Vusers:
每秒点击率Hits per Second