1、如果服务器如预期的一样执行，那么呑吐量会随着它每秒的点击量而增加。如果点击的次数增加而呑吐量恒定或减少，就说明服务器无法执行增加的请求（每秒点击率），结果就是事务响应时间的增加。2 Vuser图在负载测试场景执行期间，Vuser 会在执行事务时生成数据。通过 Vuser 图您可以确定场景执行期间 Vuser 的整体运行情况。这些图会显示 Vuser 状态、已完成脚本的 Vuser 数以及集合统计信息。将这些图与事务图相结合可以确定 Vuser 数目对事务响应时间的影响。2.1 “运行 Vuser ”图 （Running Vusers）1 “运行 Vuser”图显示测试期间每秒钟执行 Vuser
2、 脚本的 Vuser 数及其状态。此图2 对于确定任意给定时刻服务器上的 Vuser 负载非常有用。默认情况下，此图仅显3 示处于运行状态的 Vuser。要查看其他 Vuser 状态，请将筛选条件设置为所需的状4 态。2.2 “集合”图 （Rendezvous）“集合”图显示在集合点处释放 Vuser 的时间以及每个点释放的 Vuser 数。此图有助于了解事务性能时间。通过对比“集合”图和“平均事务响应时间”图，您可以看到由集合产生的负载峰值如何影响事务时间。3 错误图3.1 “每秒错误数（按描述）”图 （Error Statistics） “每秒错误数（按描述）”图显示负载测试场景运行期间每
3、秒所发生错误的平均数（按错误描述分组）。在图例中显示错误描述。错误数越小越好，通过错误数可以定位系统在负载情况下，什么时候出错，查找出系统错误的原因。常见错误提示分析：1、Error: Failed to connect 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、应用服务没有死应用服务参数设置问题例：在
4、许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25。 C、数据库的连接在应用服务的性能参数可能太小了；或数据库启动的最大连接数（跟硬件的内存有关）2、 Error: Page download timeout （120 seconds） has expired可能是以下原因造成 A、应用服务参数设置太大导致服务器的瓶颈 B、页面中图片太多 C、在程序处理表的时候检查字段太多4 事务图4.1 “平均事
5、务响应时间”图 （Average Transaction Response Time） “平均事务响应时间”图显示负载测试场景运行期间每秒内用于执行事务的平均时间。X 轴表示自场景开始运行以来经过的时间。Y 轴表示每个事务的平均响应时间（秒）。响应时间标准可参考国外的3/5/10原则（见术语章节-响应时间部分）。平均事务响应时间会随着负载用户数的增加而增加。平均事务响应时间在规定时间内越平稳越好。响应时间出现波峰越多系统越不稳定。4.2“负载下的事务响应时间”图 （Running Vuser Average Transaction Response Time）“负载下的事务响应时间”图是“运行
6、 Vuser”图与“平均事务响应时间”图的组合，显示负载测试场景运行期间相对于任何给定时间点运行的 Vuser 数目的事务时间。此图有助于查看 Vuser 负载对性能时间的总体影响，在分析逐渐加压的场景时最有用。 在Analysis的“运行 Vuser”图 - 点击右键 选择“合并图表”（Merge Graphs）- 在图表选项，选择“平均事务响应时间”图；在合并类型选项，选择“Correlate”。即可生成“负载下的事务响应时间”图。图4-1 “负载下的事务响应时间”图4.3“页面细分”图 （Web Page Diagnostics图） “平均事务响应时间”图点击右键选择“Show Tran
7、saction Breakdown Tree” - 在“Breakdown Tree”选择一要查看“页面细分”图的事务 - 点击右键，选择“Web Page Diagnostics for XX（事务）”，生成“页面细分”图。 注：生成“页面细分”图的前提是，执行场景时，需要在Controller Diagnostics Configuration，勾上“Web Page Diagnostics”。 正常的从浏览器发送一个请求到最后显示，整个过程由以下时间片组成，如图4-2所示。图4-2 网络时间解析图1） DNS解释时间（DNS Resolution）浏览器向服务器发送一个请求，一般情况下，
8、客户端的请求首先被发送到DNS服务器上，通过域名解析，将DNS名解析为IP地址。其中域名解析的时间就是DNS解析时间（DNS Resolution）。通过这个时间可以确定DNS服务器或DNS服务器的配置是否有问题。如果DNS服务器运行情况良好，这个时间会比较小。2） 连接时间（Connection）DNS解析完成后，请求被送到Web服务器，之后浏览器与Web服务器之间需要建立一个初始化连接。建立连接的过程就是连接时间（Connection）。通过这个时间就可以判断网络的情况，也可以判断Web服务器是否能够响应这个请求。如果正常，这个时间会比较小。3） 第一个字节时间（First Buffer）
9、建立连接后，Web服务器发出第一个数据包，经过网络传输到客户端，浏览器成功接收到第一个字节的时间就是First Buffer的时间。这个度量时间不仅可以表示Web服务器的延迟时间，还可以表示网络反应时间。4） 接收时间（Receive）从浏览器接收第一个字节起，知道成功收到最后一个字节，下载完成为止。5） Client Time: 请求在客户端浏览器延迟时间，可能是由于客户端浏览器的ThinkTime或者客户端其他方面引起的延迟；6） Error Time：从发送一个HTTP请求，到Web服务器发送回一个HTTP错误信息所需要的时间。4.4“每秒事务数”（Transactions per se
10、cond 简称：TPS）性能又一关键数据指标TPS，该数据反映了系统在同一时间内处理业务最大能力，这个数据越高，说明系统处理能力越强。当然TPS会受到负载的影响，也会随着负载的增加而逐渐增加，当系统进入繁忙的时候，TPS会下降。当TPS下降要查看是否服务处理能力下载，是否出现事务等待排队，导致响应时间的增加等情，结合响应时间指标和服务器指标分析。5 Web资源图5.1“每秒点击次数”图 （Hits per Second）“每秒点击次数”图显示负载测试场景运行期间的每一秒内Vuser向Web服务器发出的 HTTP 请求数。此图可帮助您根据点击次数对 Vuser 生成的负载量进行评估。可以将此图与
11、“平均事务响应时间”、“负载用户数”图进行比较，查看点击次数对事务性能的影响。点击随负载用户增加而增加，点击次数越多越好。点击数增加，响应时间增加超出规定时间，说明系统服务器排队处理事务，需要关注服务器的磁盘、内存、和CPU使用情况确定系统性能问题。5.2“吞吐量”图 （Throughput）“吞吐量”图显示在负载测试场景运行的每一秒，服务器上的吞吐量。吞吐量以字节为单位，表示 Vuser 在任意给定的一秒内从服务器接收的数据量。此图可帮助您根据服务器吞吐量对 Vuser 生成的负载量进行评估。可以将此图与“平均事务响应时间”图进行比较，查看吞吐量对事务性能的影响。吞吐量会随负载用户增加受影响
12、。当负载用户数量增加，吞吐量增加，响应时间在规定范围，说明系统稳定。当负载用户增加，吞吐量增加或者下降，响应时间超出规定范围，说明系统有问题或者服务处理能力下载。6 系统资源图 LoadRunner可监控Windows资源、UNIX资源。下面说下UNIX资源的三个重要的指标。6.1 LoadRunner下监控的UNIX资源指标6.1.1平均负载（Average load）上一分钟同时处于“就绪”状态的平均进程数，数值最好小于 CPU个数 * 核心数 * 0.7。如果等于，那就是说CPU正好满负载，再多一点，可能就要出问题了，有任务不能被及时分配处理器。6.1.2 CPU利用率（CPU util
13、ization）CPU 的使用时间百分比。如果该值持续超过95%，表明瓶颈是CPU。那也许该增加一个处理器或换一个更快的处理器，如果服务器专用于SQL Server，可接受的最大上限是80-85%。合理使用范围应该在60%-70%，最好不要超过75%。6.1.3 每秒传入的包数（Paging rate）每秒钟读入物理内存或写入页面文件的页数，如果该数值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈，也有可能是内存访问命中率底。6.2使用NMON工具监控Linux资源监控前需要根据服务器的操作系统来安装相应版本的NMON（NMON for Solaris, NMON for L
14、inux）。为了配合性能测试，我们往往需要将一个时间段内系统资源消耗情况记录下来，这时可以使用命令：./nmon -f -s 10 -c 360。说明：./nmon：反斜杠后面的命令名为安装的一个文件名（不同版本可能不同）-f ：按标准格式输出文件名称：_YYYYMMDD_HHMM.nmon-s ：每隔n秒抽样一次，这里为10秒-c ：取出多少个抽样数量，这里为360，即监控=10*360/3600=1小时该命令启动后，会在nmon所在目录下生成监控文件，并持续写入资源数据，直至360个监控点收集完成即监控1小时，这些操作均自动完成，无需手工干预，测试人员可以继续完成其他操作。如果想停止该监控
15、，需要通过“#ps ef|grep nmon”查询进程号，然后杀掉该进程以停止监控。注：对于NMON for Solaris，可以使用命令：./sadc 10 360 test。即每隔10秒抽样一次，抽样360次。test是文件名，同时还会生成一个test.hostname_yymmdd_hhmm.nmon格式的数据。由于在Solaris，直接输入上面命令，若关闭shell窗口，或输入命令后回车，则直接退出执行命令。为了使命令能在后台执行，命令要改为：nohup ./sadc 10 360 test &UNIX操作系统监控命令：vmstat iostat topsatsag；6.2.1 系统资
16、源汇总（SYS_SUMM）系统资源汇总如下图所示，显示了系统CPU及IO资源的总体使用情况。CPU%值持续超过95%，表明瓶颈是CPU。如果服务器专用于SQL Server，可接受的最大上限是80-85%。图6-1 系统资源汇总6.2.2 磁盘资源汇总（DISK_SUMM） 可以通过磁盘的详细信息来帮助判断磁盘IO值偏高的原因（若认为磁盘IO值偏高）。如果磁盘写入数据较多，平均值达到每秒450KB，可以判断这是造成磁盘IO偏高的主要原因，那么结合系统实际设置，可以进一步确定造成问题的原因，如系统日志级别过低等等。下图是磁盘资源汇总图：图6-2 磁盘资源汇总6.2.3 内存资源（MEM）内存资源
17、主要有两项指标：实际剩余内存百分比（Real Free %），实际内存总体大小（Real total（MB）。通过这两个指标，可以知道内存的使用情况。下图为内存资源图。图6-3 内存资源7 网络监控器图7.1 “网络延迟时间”图（Network Delay Time）在使用“网络延迟时间”图前，需要添加要监控的路径。例如需要监控数据库服务器和Vuser Load Generator 之间的网络延迟时间，在Controller 的“网络延迟时间”图 - 点击右键，选择“Add Measurements” - 在Network Delay Time对话框的“Monitor the network
18、delay from machine:”区域点击“Add” 输入数据库服务器的IP地址 在“To machine（s）:”区域点击“Add” 输入Vuser Load Generator（即负载机）的IP地址 点击“OK”，即可监控数据库服务器和Vuser Load Generator 之间的网络延迟时间。下图将网络延迟显示为场景已用时间的函数。图中显示，在场景开始后的第 8 分钟，有 16 毫秒的延迟。图7-1 “网络延迟时间”图也可以通过“网络子路径时间”图、“网络段延迟”图来查看某网络段的延迟时间。为了验证网络瓶颈，可以合并多个图来确定瓶颈是否由网络引起。例如，使用“网络延迟时间”和“运
19、行 Vuser”图可以确定Vuser的数目如何影响网络延迟。“网络延迟时间”图显示负载测试场景运行期间的网络延迟。“运行 Vuser”图显示正在运行的Vuser数目。在下面的合并图中，将网络延迟与正在运行的 Vuser 数目进行了对比。此图显示，当 10 个 Vuser 全部运行时，出现了22毫秒的网络延迟，暗示网络可能已超载。图7-2 “网络延迟时间-运行Vuser”图8 数据库服务器资源图8.1 Oracle服务器监控度量使用LoadRunner监控Oracle服务器需要设置Oracle监控环境，具体请参与LR11的用户操作手册HP LoadRunner Controller User G
20、uide如何设置 Oracle 监控环境章节，或参考研发-orcal数据库监控配置。监控 Oracle 服务器时最常使用以下度量（来自 V$SYSSTAT 表）：度量说明CPU used by this session从用户调用开始到结束之间会话使用的 CPU 时间（几十毫秒）。部分用户调用可以在 10 毫秒内完成，因此用户调用的启动和结束时间可能相同。在此例中，统计数据增加了 0 毫秒。操作系统报告中可能存在类似的问题，尤其是在频繁进行上下文切换的系统上。Bytes received viaSQL*Net from client通过 Net8 从客户端收到的总字节数。Logons curre
21、nt当前登录总次数。Opens of replaced files因不再位于进程文件高速缓存而需要重新打开的文件总数。User calls每次登录、解析或执行时， Oracle 都分配资源（调用状态对象）以跟踪相关用户调用数据结构。在确定活动时，用户调用与 RPI 调用的比率可以表明用户发送到Oracle 的各类请求将生成多少内部工作量。SQL*Net roundtrips to/from client向客户端发送和从客户端接收的 Net8 消息总数。Bytes sent via SQL*Net toclient从前台进程发送到客户端的总字节数。Opened cursors current当前
22、打开光标的总数。DB block changes此统计数据与一致性更改密切相关，计算的是对 SGA中所有块进行更改（作为更新或删除操作的一部分）的总次数。这些更改将生成重做日志条目，如果提交事务，将永久更改数据库。此统计数据是数据库总负载的粗略表示，指示缓冲区被弄脏的比率（各个事务级别可能有所不同）。Total file opens实例打开文件的总次数。每个进程都需要许多文件（控制文件、日志文件、数据库文件）才能使用数据库。8.1.1 添加Oracle自定义计数器 LR自带的计数器，有时候不足以满足监控的需求，故需要手动添加自定义的Oracle计数器。 添加步骤如下：1） 在LR的安装目录“H
23、PLoadRunnerdatmonitors”下找到文件“vmon.cfg”2） 打开该文件“vmon.cfg”，找到第三行“CustomCounters=xx”（其中xx为目前已定义的自定义计数器个数），把自定义计数器个数“xx”改为（原个数+本次添加的个数）总和3） 在该文件“vmon.cfg”中以下面格式插入相应的计数器定义说明：;Custom0Name must be uniqueName=Five HundredDescription=This counter always returns 500.Query=SELECT 500 FROM DUALIsRate=0 其中，“Cust
24、om0”的序号 “0”应改为相应的序号（序号必须由“0”开始连续加1递增，如0，1，2；若本来已有自定义计数器，由序号由原有序号开始递增。）下面为增加的12个计数器：Name=库快存命中率Description=命中率应大于0.9Query=SELECT 100*（sum（pins-reloads）/sum（pins） from v$librarycache Custom1Name=高速缓存区命中率Query=SELECT round（1-SUM（PHYSICAL_READS）/（SUM（DB_BLOCK_GETS） + SUM（CONSISTENT_GETS）, 4） * 100 FROM
25、（SELECT CASE WHEN NAME=physical reads THEN VALUE END PHYSICAL_READS,CASE WHEN NAME = db block gets THEN VALUE END DB_BLOCK_GETS,CASE WHEN NAME = consistent gets THEN VALUE END CONSISTENT_GETS FROM V$SYSSTAT WHERE Name IN （,）Custom2Name=共享区库缓存区命中率Description=命中率应大于0.99Query=Select round（sum（pins-relo
26、ads）/sum（pins） * 100, 2） from v$librarycacheCustom3Name=共享区字典缓存区命中率Description=命中率应大于0.85Query=Select round（sum（gets-getmisses-usage-fixed）/sum（gets） * 100, 2） from v$rowcacheCustom4Name=检测回滚段的争用Description=应该小于1%Query=select round（sum（waits）/sum（gets） * 100, 2） from v$rollstatCustom5Name=检测回滚段收缩次数Description=应该Query=select sum（shrinks） from v$rollstat, v$rollname where v$rollstat.usn = v$rollname.usnCustom6Name=监控表空间的I/O读总数Description=监控表空间的I/OQuery=select sum（f.phyrds） pyr from v$filestat f, dba_data_files df where f.file# = df.file_idCustom7Name=监控表空间的I/O块读总数
