性能测试的一些帖子

1、copy Bookmark· (转)实现LoadRunner多个场景的顺序执行应用场景假设有3个不同的测试场景，分别为并发登录、核心业务、可靠性测试，3个场景有先后执行顺序。由于白天测试机器另有用处，只能在晚上进行性能测试，这时我们的期望是能否把测试场景都设定好之后晚上自动运行，第二天我们回来看测试结果呢？答案是肯定的，可以有两种方式实现。 第一种，相对简单充分利用LR Controller里面Group的功能。新建一个场景把3个脚本都添加进来，在Edit Schedule中选择“Schedule by Group”的方式，在StartTime中设置3个脚本的运行顺序为“Start

2、when Group xxx finished”，并在“Scenario Start Time”中设定场景在晚上的运行启动时间。设定完定时执行场景后，点击StartScenario按钮，会出现一个倒计时窗口，这样在固定的某个时间上，测试场景中的3个脚本将乖乖的按照设定的先后顺序进行测试。注意，如果没有点击StartScenario按钮激活测试，是不会真正进行测试的。（感谢Athenst朋友的提醒，_）第二种，比较灵活我们把应用场景稍微扩展一下，假设其中1、3场景只有一个测试脚本，而核心业务场景由数据录入、数据查询、数据上报3个脚本组成，同样的，3个场景仍需按顺序进行测试。这时如果采用第一种方式

3、，由于第2个场景有3个脚本，所以第三个脚本的启动时间就是一个问题了。由于Controller中每个脚本都对应一个Group，而且GroupName不能重复，这时第三个场景的StartTime中“Start when group finished”则只能是选择第二个场景中的某个Group，而并非是第二个场景的3个脚本都完成之后再进行，无法达到我们的初衷。这时，可以通过命令行的方式来进行。首先创建并设置好3个测试场景，再创建一个一个批处理程序按先后顺序调用这3个场景进行测试，最后通过Windows的定时任务设定批处理的执行时间。批处理示例如下：clsSET M_ROOT="D:Progr

4、am FilesMIMercury LoadRunnerbin"%M_ROOT%wlrun.exe -TestPath "D:Program FilesMIMercury LoadRunnerscenarioTestTestScen_1.lrs" -Run%M_ROOT%wlrun.exe -TestPath "D:Program FilesMIMercury LoadRunnerscenarioTestTestScen_2.lrs" -Run%M_ROOT%wlrun.exe -TestPath "D:Program FilesMI

5、Mercury LoadRunnerscenarioTestTestScen_3.lrs" -Run这种方式比较灵活，但需要注意在ResultSettings中设置“Automatically create a results directory for each scenario execution”，以免后面的测试结果覆盖了前面的。 另外补充一下，如果想对某个脚本进行50、100、150.等用户数递增的测试，也可以用以上方法实现，但需要注意的是将事务名称区分开以便进行分析。· 如何在LoadRunner中监控Oracle数据库(转)1、使用LR自带的监控引擎 在LR的c

6、ontroller上安装oracle客户端：这一步就不用说了，安装直接Setup，安装就OK了。1）安装完后，先配置一下Net Configuration Assistant。记住配置的服务名。配置成功会显示：正在连接.测试成功。2）用sqlplus连接一下，看是否可以连接成功，打开sqlplus输入oracle用户名密码和主机字符串。查看是否登录成功。添加oracle计数器：3）登录成功后，打开LR的controller.，在可用图中选择oracle，点击add measurements,再点击Advanced，如下所示：这里我们用LR native monitors。4）在Monitore

7、d Server Machines区域，添加oracle服务器所在的IP。5）再在Resource Measurements on:IP区域点击添加，弹出对话框如下：6）输入相应的信息，这里的orcl就是前面在Net Configuration Assistant配置的服务名。7）点击OK，这里我们应该可以看到可以添加oracle的计数器了，如下所示：2、使用Sitescope引擎不需要配置Net Configuration Assistant。1）在第一个图choose monitor engine中选择sitescope，然后在在Monitored Server Machines区域点击A

8、dd如下所示：在这里可以选择本地或者其他机器的sitescope，如果sitescope启用了account的验证，也要写上相应的用户名密码。2）在Resource Measurements on:IP区域点击添加，弹出对话框如下：3）输入信息如图。点击OK，如下：至此就可以监控Oracle了。· LR监控linux之详解rstatd的安装(转)1. 前期准备：1,把rstatd文件解压到要监控的机器上。2,打开终端，定位到rstatd文件夹下：查看文件夹中的内容如下： rootlocalhost rpc.rstatd# lsaclocal.m4   

9、COPYING     Makefile.am    README        rstat_proc.c rup.1config.h.in   CVS         Makefile.in    rpc.rstatd.8 rstat.x      

10、; rup.cconfigure     INSTALL     missing        rstatd.8      rsysinfo.1    stamp-h.inconfigure.in install-sh mkinstalldirs rstat_main.c rsysinfo.c2.执行如下步骤：2.执行：./co

11、nfigure 命令rootlocalhost rpc.rstatd# ./configurecreating cache ./config.cachechecking for a BSD compatible install. /usr/bin/install -cchecking whether build environment is sane. yeschecking whether make sets $MAKE. yeschecking for working aclocal. foundchecking for working autoconf. foundchecking fo

12、r working automake. foundchecking for working autoheader. foundchecking for working makeinfo. foundchecking for gawk. gawkchecking for gcc. gccchecking whether the C compiler (gcc ) works. yeschecking whether the C compiler (gcc ) is a cross-compiler. nochecking whether we are using GNU C.

13、 yeschecking whether gcc accepts -g. yeschecking for a BSD compatible install. /usr/bin/install -cchecking whether ln -s works. yeschecking whether make sets $MAKE. (cached) yeschecking how to run the C preprocessor. gcc -Echecking for sys/ioctl.h. yeschecking for syslog.h. yeschecking whether time.

14、h and sys/time.h may both be included. yeschecking whether gcc needs -traditional. nochecking for ANSI C header files. yeschecking return type of signal handlers. voidupdating cache ./config.cachecreating ./config.statuskcreating Makefilecreating config.h rootlocalhost rpc.rstatd# makerm -f rst

15、at.hrpcgen -h -o rstat.h rstat.xgcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c rup.crup.c: In function 'ointopoint_v5':rup.c:256: warning: passing argument 6 of 'client->cl_ops->cl_call'?from incompatible pointer typerup.c: In function 'ointopoint_v3'

16、?rup.c:292: warning: passing argument 6 of 'client->cl_ops->cl_call'?from incompatible pointer typerup.c: In function 'main'?rup.c:317: warning: return type of 'main'?is not 'int'?rm -f rstat_xdr.crpcgen -c -o rstat_xdr.c rstat.xgcc -DHAVE_CONFIG_H -I. -I. -I.&#

17、160;    -g -O2 -c rstat_xdr.crm -f rstat_clnt.crpcgen -l -o rstat_clnt.c rstat.xgcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c rstat_clnt.cgcc -g -O2 -o rup rup.o rstat_xdr.o rstat_clnt.o gcc -DHAVE_CONFIG_H -I. -I. -I.     -g

18、 -O2 -c rsysinfo.crsysinfo.c: In function 'ointopoint_v3'?rsysinfo.c:136: warning: passing argument 6 of 'client->cl_ops->cl_call'?from incompatible pointer typersysinfo.c: In function 'main'?rsysinfo.c:160: warning: return type of 'main'?is not 'int'?gc

19、c -g -O2 -o rsysinfo rsysinfo.o rstat_xdr.o rstat_clnt.o rm -f rstat_svc.crpcgen -m -o rstat_svc.c rstat.xgcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c rstat_svc.cgcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c rstat_proc.cgcc -DHAVE_CONFIG_H

20、 -I. -I. -I.     -g -O2 -c rstat_main.crstat_main.c: In function 'main'?rstat_main.c:82: warning: return type of 'main'?is not 'int'?gcc -g -O2 -o rpc.rstatd rstat_svc.o rstat_xdr.o rstat_proc.o rstat_main.o 这之后可以执行:make check检查一下。 root

21、localhost rpc.rstatd# make installmake1: Entering directory /opt/rpc.rstatd'/bin/sh ./mkinstalldirs /usr/local/bin /usr/bin/install -c rup /usr/local/bin/rup /usr/bin/install -c rsysinfo /usr/local/bin/rsysinfo/bin/sh ./mkinstalldirs /usr/local/sbin /usr/bin/install -c&#

22、160;rpc.rstatd /usr/local/sbin/rpc.rstatdmake1: Nothing to be done for install-data-am'.make1: Leaving directory /opt/rpc.rstatd'rootlocalhost rpc.rstatd# ./rpc.rstatdrootlocalhost rpc.rstatd# rpcinfo -p   program vers proto   port    100000  

23、0; 2   tcp    111 portmapper    100000    2   udp    111 portmapper    100024    1   udp    797 status    100024    1

24、60;  tcp    800 status    100001    5   udp    900 rstatd    100001    3   udp    900 rstatd    100001    2   udp&#

25、160;   900 rstatd    100001    1   udp    900 rstatdrootlocalhost rpc.rstatd# 3.    可能会出现的错误： 1,若RPC服务没有成功启动。2,若目标主机上开启了防火墙，阻挡了RPC服务。在LR中添加时可能会出现如下错误： Monitor name :UNIX Resources. Cannot initialize the mo

26、nitoring on 5. Error while creating the RPC client. Ensure that the machine can be connected and that it runs the rstat daemon (use rpcinfo utility for this verification). Detailed error: RPC: Failed to create RPC client.RPC-TCP: Failed to establish RPC server address.RPC-TCP: RPC Server &

27、lt;100001, 3, 17> is not registered on host '5'. (entry point: CFactory:Initialize).   MsgId: MMSG-47190 Monitor name :UNIX Resources. Internal rpc error (error code:2). Machine: 5. Hint: Check that RPC on this machine is up and running. Check that rstat

28、 daemon on this machine is up and running (use rpcinfo utility for this verification). Details: RPC: RPC call failed.RPC-TCP: recv()/recvfrom() failed.RPC-TCP: Timeout reached. (entry point: Factory:CollectData). MsgId: MMSG-47197 至此完毕。· Error -266121、设置代理服务器可能引起这个MERR-26612，取消代理服务器的设置解决2、

29、取消选中run time settings-browser emulation-download non-html resources.解决3、没有设置关联，在录制完成之后F8，自动关联看看 4、服务器程序本身问题· LoadRunner压力测试结果分析探讨(转)分析原则：1. 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）2. 查找瓶颈时按以下顺序，由易到难。服务器硬件瓶颈  网络瓶颈（对局域网，可以不考虑）  服务器操作系统瓶颈（参数配置）  中间件瓶颈（参数配置，数据库，web服务器等）  应用瓶颈（SQL语

30、句、数据库设计、业务逻辑、算法等）分析的信息来源：1. 根据场景运行过程中的错误提示信息2. 根据测试结果收集到的监控指标数据一错误提示分析分析实例：分析：A、应用服务死掉。（小用户时：程序上的问题。程序上处理数据库的问题，实际测试中多半是服务器链接的配置问题）B、应用服务没有死（应用服务参数设置问题）对应的Apache和tomcat的最大链接数需要修改，如果连接时收到connection refused消息，说明应提高相应的服务器最大连接的设置，增加幅度要根据实际情况和服务器硬件的情况来定，建议每次增加25%！C、数据库的连接(数据库启动的最大连接数（跟硬件的内存有关）)D、我们的应用程序s

31、pring控制的最大链接数太低2. Error: Page download timeout (120 seconds) has expired分析：A、应用服务参数设置太大导致服务器的瓶颈B、页面中图片太多C、在程序处理表的时候检查字段太大多D、实际测试时有些资源需要请求外网，而我们的测试环境是局域网环境分析：A、脚本设计错误，造成页面异常。服务器有响应！B、并发数过大，造成服务器响应延迟。4. Error page “text=xxxxx”分析：A、脚本设计问题，例如，前一脚本修改了某些内容，造成后面的脚本访问异常。B、不确定因素，有时候回放正常的脚本，一放到场景中就出现这样的错误。只能反

32、复修改脚本！二监控指标数据分析1Vusers数Loadrunner 系统设置的虚拟用户数目。Vuser去实际调用事先制作的脚本文件中的应用。每个Vuser产生响应的操作，所有的操作对服务器形成并发。颜色 比例 度量 图最小值 图平均值 图最大值 图中间值 图SD1 Run 0.0 21.25 44 41 21.276在实际测试中，Vusers可以根据实际情况的需要，在测试过程中增加或者减少。2最大并发用户数：颜色 比例 度量 最小值 平均值 最大值 SD应用系统在当前环境下能承受的最大并发用户数。在方案运行中，如果出现了大批用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前

33、环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。从上图可以看出：在测试运行到4个小时左右的时候，apache的点击数/秒开始迅速增加！3业务操作响应时间：使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。颜色 比例 度量1 最小值1 平均值1 最大值分析事务的响应情况，要每次详细分析，目前还只能观察到响应时间过长的事务！4每秒点击数负载测试期间每秒内 Vuser 在 Web 服务器上点击的次数。可根据点击次数来估算 Vuser 生成的负载数。颜色 比例 度量 图最小值 平均值 图最大值 图中间值 图SD1 点击次数 69.9

34、08 105.736 130.244 103.666 12.186从图中不难看出，在4小时的时候，点技数明显增高。和apache的每秒点击数增大的时间相吻合！5吞吐量负载测试期间 Web 服务器上的吞吐量(字节)。吞吐量表示在任何指定秒内 Vuser 从服务器接收到的数据量。此图可估计 Vuser 生成的负载量(服务器吞吐量)。颜色 比例 度量 图最小值 平均值 图最大值 图中间值 图SD1 Throughput 1257502.795 1375591.372 1525865.047 1372743.691 49130.473同样，从图中可以看出，在4个小时的时候，web服务器的吞吐量开始增高

35、。在图中还可以看到吞吐量的走势图，从开始到进行到4个小时反弹之前呈降低的趋势，这是因为系统在初期调用的资源都是直接来之服务器，运行一段时间后系统的部分资源来自缓存。6下载组件大小每个页面的组件大小，且包括组件的标头的大小！页面组件大小的分析表格比较复杂，实际分析中可以通过loadrunner的报告分析工具来分析。页面组件大小分析主要是找到页面中比较庞大的组件，如果其影响到了页面的下载速度，则要想办法将其改小！7Apache资源显示APACHE web服务器上的资源摘要。前面已经提到过以并发点击数为主。颜色 比例 度量 最小值 平均值 最大值 SD三服务器资源监控指标：（目前通过top监察）内存

36、：Linux资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。实际测试中，当并发点击数出现突然剧增前后，内存的PR 值则居高25不下。说明目前测试的系统中内存存在瓶颈！内存资源成为系统性能的瓶颈的征兆:很高的换页率(high pageout rate);进程进入不活动状态;交换区所有磁盘的活动次数可高;可高的全局系统CPU利用率;内存不够出错(out of memory errors)处理器：Linux资源监控中指标CPU占用率持续超过80%（对该值的要求，根据具体应用和机器配置而要求不同

37、，有资料表明95），表明瓶颈是CPU。实际测试中，当并发点技数出现突然增加前后，cpu的占用率持续保持在86以上！说明，目前系统用应用的cpu也是测试的瓶颈！CPU资源成为系统性能的瓶颈的征兆:很慢的响应时间(slow response time)CPU空闲时间为零(zero percent idle CPU)过高的用户占用CPU时间(high percent user CPU)过高的系统占用CPU时间(high percent system CPU)长时间的有很长的运行进程队列(large run queue size sustained over time)四数据库服务器：数据库服务器目前

38、测试观察，当web服务器点击率增大时，观察mysql数据库的最大连接数，仍未超过系统设置的最大连接数。所以，暂时未发现数据库的瓶颈！五结论以上报告分析中的数据、图标均来自同一次测试。是在平时测试中挑出的一次现象比较明显，比较利于观察的作为分析案例。根据以上综合分析，当前测试环境下，当应用系统产生最大533.667的并发压力。平均负载压力114.352。根据分析，用户在4个小时的时候，并发数迅速增加前后的值在400左右！分析结果跟实际测试的硬件环境以及测试脚本有一定关系。同时，测试服务器的硬件配置和实际服务器的配置还有一定的差距！· LoadRunner常见测试结果分析(转)在测试过程

39、中，可能会出现以下常见的几种测试情况： 一、当事务响应时间的曲线开始由缓慢上升，然后处于平衡，最后慢慢下降这种情形表明：* 从事务响应时间曲线图持续上升表明系统的处理能力在下降，事务的响应时间变长；* 持续平衡表明并发用户数达到一定数量，在多也可能接受不了，再有请求数，就等待；* 当事务的响应时间在下降，表明并发用户的数量在慢慢减少，事务的请求数也在减少。如果系统没有这种下降机制，响应时间越来越长，直到系统瘫痪。从以上的结果分析可发现是由以下的原因引起：1. 程序中用户数连接未做限制，导致请求数不断上升，响应时间不断变长；2. 内存泄露；二、CPU的使用率不断上升，内存的使用率也是不断上升，其

40、他一切都很正常；表明系统中可能产生资源争用情况；引起原因：开发人员注意资源调配问题。三、 所有的事务响应时间、cpu等都很正常，业务出现失败情况；引起原因：数据库可能被锁，就是说，你在操作一张表或一条记录，别人就不能使用，即数据存在互斥性；当数据量大时，就会出现数据错乱情况。· (转)LoadRunner分析结果图功能说明2009-09-06 17:06:12Transactions（用户事务分析）用户事务分析是站在用户角度进行的基础性能分析。1、Transation Sunmmary（事务综述）对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直

41、接判断出系统是否运行正常。2、Average Transaciton Response Time（事务平均响应时间）“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。3、Transactions per Second（每秒通过事务数/TPS）“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。

42、分析TPS主要是看曲线的性能走向。将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。4、Total Transactions per Second（每秒通过事务总数）“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。5、Transaction Performance Sunmmary（事务性能摘要）“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。重点关注事务的平均和最大执行时间，如果

43、其范围不在用户可以接受的时间范围内，需要进行原因分析。6、Transaction Response Time Under Load（事务响应时间与负载）“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据，为扩展用户系统提供参考。此图可以查看虚拟用户负载对执行时间的总体影响，对分析具有渐变负载的测试场景比较有用。7、Transaction Response Time(Percentile)（事务响应时间(百分比)）“事务响应时间(百分比)”是根据测试结果进行分析而得到的综合分

44、析图，也就是工具通过一些统计分析方法间接得到的图表。通过它可以分析在给定事务响应时间范围内能执行的事务百分比。8、Transaction Response Time(Distribution)（事务响应时间(分布)）“事务响应时间(分布)”显示在场景运行过程中，事务执行所用时间的分布，通过它可以了解测试过程中不同响应时间的事务数量。如果系统预先定义了相关事务可以接受的最小和最大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围内。 Web Resources（Web资源分析）Web资源分析是从服务器入手对Web服务器的性能分析。1、Hits per Second（每秒点击

45、次数）“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。2、Throughput（吞吐率）“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。“吞吐率”图和

46、“点击率”图的区别：“吞吐率”图，是每秒服务器处理的HTTP申请数。“点击率”图，是客户端每秒从服务器获得的总数据量。3、HTTP Status Code Summary（HTTP状态代码概要）“HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状态代码数，该图按照代码分组。HTTP状态代码表示HTTP请求的状态。4、HTTP Responses per Second（每秒HTTP响应数）“每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回其它各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，也可以通过

47、对图中显示的结果进行分组，进而定位生成错误的代码脚本。5、Pages Downloader per Second（每秒下载页面数）“每秒下载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。使用此图可依据下载的页数来计算Vuser生成的负载量。和吞吐量图一样，每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。但是吞吐量考虑的各个资源极其大小（例，每个GIF文件的大小、每个网页的大小）。而每秒下载页面数只考虑页面数。注：要查看每秒下载页数图，必须在R-T-S那里设置“每秒页面数(仅HTML模式)”。6、Retries per Second（每秒重试次数）“每秒重试

48、次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。在下列情况将重试服务器连接：A、初始连接未经授权B、要求代理服务器身份验证C、服务器关闭了初始连接D、初始连接无法连接到服务器E、服务器最初无法解析负载生成器的IP地址7、Retries Summary（重试次数概要）“重试次数概要”显示场景或会话步骤运行过程中服务器尝试的连接次数，它按照重试原因分组。将此图与每秒重试次数图一起使用可以确定场景或会话步骤运行过程中服务器在哪个时间点进行了重试。8、Connections（连接数）“连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。借助此图，可以知道何时需要添加其他

49、连接。例：当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）。9、Connections Per Second（每秒连接数）“每秒连接数”显示方案在运行过程中每秒建立的TCP/IP连接数。理想情况下，很多HTTP请求都应该使用同一连接，而不是每个请求都新打开一个连接。通过每秒连接数图可以看出服务器的处理情况，就表明服务器的性能在逐渐下降。10、SSLs Per Second（每秒SSL连接数）“每秒SSL连接数”显示场景或会话步骤运行的每一秒内打开的新的以及重新使用的SSL连接数。当对安全服务器打开TCP/IP连接后，浏览器将打开SSL连接。We

50、b Page Breakdown（网页元素细分）“网页元素细分”主要用来评估页面内容是否影响事务的响应时间，通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的元素。1、Web Page Breakdown（页面分解总图）“页面分解”显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。“页面分解”图可以按下面四种方式进行进一步细分：1)、Download Time Breaddown（下载时间细分）“下载时间细分”图显示网页中不同元素的下载时间，同时还可按照下载过程把时间进行分解，用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。2)

51、、Component Breakdown(Over Time)（组件细分(随时间变化)）“组件细分”图显示选定网页的页面组件随时间变化的细分图。通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。3)、Download Time Breakdown(Over Time)（下载时间细分(随时间变化)）“下载时间细分(随时间变化)” 图显示选定网页的页面元素下载时间细分（随时间变化）情况，它非常清晰地显示了页面各个元素在压力测试过程中的下载情况。“下载时间细分”图显示的是整个测试

52、过程页面元素响应的时间统计分析结果，“下载时间细分(随时间变化)”显示的事场景运行过程中每一秒内页面元素响应时间的统计结果，两者分别从宏观和微观角度来分析页面元素的下载时间。4)、Time to First Buffer Breakdown(Over Time)（第一次缓冲时间细分(随时间变化)）“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一次缓冲之前的这段时间，场景或会话步骤运行的每一秒中每个网页组件的服务器时间和网络时间（以秒为单位）。可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。First Buffer Time：是指客户端与服务器端建立连

53、接后，从服务器发送第一个数据包开始计时，数据经过网络传送到客户端，到浏览器接收到第一个缓冲所用的时间。2、Page Component Breakdown（页面组件细分）“页面组件细分”图显示每个网页及其组件的平均下载时间（以秒为单位）。可以根据下载组件所用的平均秒数对图列进行排序，通过它有助于隔离有问题的组件。3、Page Component Breakdown(Over Time)（页面组件分解(随时间变化)）“页面组件分解(随时间变化)”图显示在方案运行期间的每一秒内每个网页及其组件的平均响应时间 （以秒为单位）。4、Page Download Time Breakdown（页面下载时间

54、细分）“页面下载时间细分”图显示每个页面组件下载时间的细分，可以根据它确定在网页下载期间事务响应时间缓慢是由网络错误引起还是由服务器错误引起。“页面下载时间细分”图根据DNS解析时间、连接时间、第一次缓冲时间、SSL握手时间、接收时间、FTP验证时间、客户端时间和错误时间来对每个组件的下载过程进行细分。5、Page Download Time Breakdown(Over Time)（页面下载时间细分(随时间变化)）“页面下载时间细分(随时间变化)”图显示方案运行期间，每一秒内每个页面组件下载时间的细分。使用此图可以确定网络或服务器在方案执行期间哪一时间点发生了问题。“页面组件细分(随时间变化

55、)”图和“页面下载时间细分(随时间变化)”图通常结合起来进行分析：首先确定有问题的组件，然后分析它们的下载过程，进而定位原因在哪里。6、Time to First Buffer Breakdown（第一次缓冲时间细分）“第一次缓冲时间细分”图显示成功收到从Web服务器返回的第一次缓冲之前的这一段时间内的每个页面组件的相关服务器/网路时间。如果组件的下载时间很长，则可以使用此图确定产生的问题与服务器有关还是与网络有关。网络时间：定义为第一个HTTP请求那一刻开始，直到确认为止所经过的平均时间。服务器时间：定义为从收到初始HTTP请求确认开始，直到成功收到来自Web服务器的一次缓冲为止所经过的平均

56、时间。7、Time to First Buffer Breakdown(Over Time)（第一次缓冲时间细分(随时间变化)）“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一个缓冲之前的这段时间内，场景运行的每一秒中每个网页组件的服务器时间和网络时间。可以使用此图确定场景运行期间服务器或网络出现问题的时间点。8、Downloader Component Size(KB)（已下载组件大小）“已下载组件大小”图显示每个已经下载的网页组建的大小。通过它可以直接看出哪些组件比较大并需要进一步进行优化以提高性能· 第一次缓冲时间2009-08-26 10:32:36

57、Time to First Buffer Breakdown(Over Time)第一次缓冲时间细分（随时间变化）。此分析图显示成功收到从Web服务器返回的第一次缓冲之前这段时间内，场景或会话步骤运行的每一秒中每个网页组件的服务器时间和网络时间。通过此图可确定场景或会话步骤运行期间服务器或网络出现问题的时间。NetWork Time场景或会话步骤运行的每一秒中每个网页组件的网络时间。Server Time 场景或会话步骤运行的每一秒中每个网页组件的服务器时间。=First buffer是指从发出第一个http请求到收到第一个字节返回的时间。它是根据收到ACK的时间来划分成两部份：网络时间+服务

58、器时间。网络时间是从发出第一个http请求到收到ACK的时间。（也就是在网络上传送和收回所花的时间）服务器时间是从收到ACK到第一个字节返回的时间。（也就是服务器对请求处理的时间）first buffer= 服务器处理+网络下载时间如果有很多non-html资源，需要检查windows 或者linux 的网卡流量以及中间的路由器、交换间的带宽注：ACK是TCP首部中的确认标志，对已接受到的TCP报文进行确认。英文缩写: ACK (ACKnowledge Character）中文译名: 确认字符分类: 传输与接入解释: 在数据通信传输中，接收站发给发送站的一种传输控制字符。它表示确认发来的数据已

59、经接受无误· LoadRunner processor、memory、network interface性能对象 常用性能计数器说明(转)2009-08-06 10:58:20TPS  1   Transactions Per Second 的 缩 写， 也 就 是 事 务 数/ 秒         2   Throughtput Per Second 的缩写，单位：Byte/second 字节/秒，也就是吞吐量啦。  【分享】Network I

60、nterface 计数器 许多人对 Kbps、KB、Mbps 等速度单位有所误解，以下简单解释一下所谓的 1.5M、3M、6M 如何计算。 所谓 1.5M 宽带，其实是指 1.5Mbps (bits per second)，亦即 1.5 x 1024 / 8 = 192KB/sec， 但这只是理论上的速度，实际上则要再扣约 12% 的 Ethernet Header, IP Header, TCP Header, ATM Header 等控制讯号，故其传输速度上限应为 169KB/sec 左右。 在传输单位的写法上，B 和 b 分别代表 Bytes 和 bits，两者的定义是不同的，

61、钱万不要混淆。 1 Byte = 8 bits 1 Kb = 1024 bits 1 KB = 1024 bytes 1 Mb = 1024 Kb 1 MB = 1024 KB 宽带最高下载理论值 1.5 M =169 KB/s 3 M =338 KB/s 6 M =676 KB/s 10 M =1126 KB/s 以上谈到的是理论值，对于实际的连接速度可以通过下载文件的方法来测试，Bytes Total/sec    是在每个网络适配器上发送和接收字节的速率，包括帧字符在内。Network InterfaceBytes Received/sec=Network InterfaceBytes Received/sec+Network InterfaceBytes Sent/sec.Current Bandwidth  指以位/每秒估计的网络接口的当前带宽。Output Queue Length