loadrunner问题集锦0225.docx

1、loadrunner问题集锦0225loadrunner小知识总结loadrunner一些小知识总结，以供大家参考1. 在启动录制脚本操作的Start Recording对话框，去掉Record the application startup前的选择，可以不录制应用程序启动时的操作，而仅录制所需的特定操作。2. 添加windows性能计数器时，必须先用管理员身份登录该台服务器，然后添加才可生效(注意先后顺序)。3. 设置DB2数据库监视：在Monitored Server Machines中配置Machine Information机器信息，Name中要填写“主机名实例名”，如“168.31.

2、6.47DB2”，其中实例名要填完整，包括节点名称。Platform选“N/A”。4. 添加windows性能计数器时，必须先用管理员身份登录该台服务器，然后添加才可生效(注意先后顺序)。5. web_reg_save_param是在web脚本中用于关联HTML语句的函数。只有在录制中的关联有效时(在录制选项中设置)，web_reg_save_param才会被自动录制。6. 设置Internet首选项的其它选项几个比较常用的：由资源引起的步骤超时是警告(Step timeout caused by resources is a warning)：如果由于资源未在超时间隔内加载而引起超时，将发出

3、警告而不是错误。对于非资源，VuGen 总是发出错误。(默认情况下为 NO)HTTP 请求连接超时(秒)(HTTP-request connect timeout(sec)：Vuser 终止之前在步骤内等待特定 HTTP 请求连接的时间(秒)。超时为服务器保持稳定并响应用户提供了机会。默认值为 120 秒。HTTP 请求接收超时(秒)(HTTP-request receive timeout(sec)：Vuser 终止之前在步骤内等待接收特定 HTTP 请求的响应时间(秒)。超时为服务器保持稳定并响应用户提供了机会。默认值为 120 秒。超时设置主要用于以下高级用户：这些用户已确定可接受的超时

4、值应该随环境而异。大多数情况下，默认设置应该足够长。如果服务器在合理的时间内并未做出响应，请检查其他与连接相关的问题，不要设置太长的超时，否则可能会导致脚本不必要地等待。网络缓冲区大小(Network buffer size)：设置用于接收 HTTP 响应的缓冲区的最大大小。如果该数据的大小超过了指定的大小，则服务器将按块发送数据，从而增加了系统开销。从 Controller 中运行多个 Vuser 时，每个 Vuser 都使用自己的网络缓冲区。该设置主要用于以下高级用户：这些用户已确定网路缓冲区的大小可能影响其脚本的性能。默认值为 12K 字节。7. 在Analysis中，可以很方便地将各个

5、分析图表拷贝出来。方法是：先切换到某个图表页(Graph)，再使用Edit?Copy to Clipboard功能，便可将该图表的图、数据等复制到剪贴板，然后就可以粘贴到需要的地方(如软件测试报告)去。8. 将参数设置为Unique时，要特别注意提供的参数列表是否足够，在Controller中分配值的选项(Allocate Vuser values in the Controller)默认设置为自动分配数据块(Automatically allocate block size)，这样的设置在场景的执行过程中往往会出问题，报出“参数不够”的错误，可以修改为由人工分配(Allocate_value

6、s for each Vuser)，为每个虚拟用户分配指定数目的参数，以便于控制。9. LR在录制脚本时有时常会出现一些乱七八糟的字符，例如：Name=save_path, Value=D:x5Cresin-2.1.12x5Cdoc以上脚本片断中用红色标出的“x5C”部分就是录制下来的乱字符，该脚本原本是为了将附件上传到服务器端保存，可录制下来的保存路径却多了以上的乱字符，导致本应的保存路径D:resin-2.1.12doc.，变为D:x5Cresin-2.1.12x5Cdoc.。要特别注意，以避免产生不必要的错误最全的软件测试工具LR中性能数据翻译 Transactions（用户事务分析）用

7、户事务分析是站在用户角度进行的基础性能分析。1、Transation Sunmmary（事务综述）对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。2、Average Transaciton Response Time（事务平均响应时间）“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。3、Transactions per Second（每

8、秒通过事务数/TPS）“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向。将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。4、Total Transactions per Second（每秒通过事务总数）“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。5、Transaction Perfo

9、rmance Sunmmary（事务性能摘要）“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。6、Transaction Response Time Under Load（事务响应时间与负载）“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据，为扩展用户系统提供参考。此图可以查看虚拟用户负载对执行时间的总体影响，对分析具有渐变负载

10、的测试场景比较有用。7、Transaction Response Time(Percentile)（事务响应时间(百分比)）“事务响应时间(百分比)”是根据测试结果进行分析而得到的综合分析图，也就是工具通过一些统计分析方法间接得到的图表。通过它可以分析在给定事务响应时间范围内能执行的事务百分比。8、Transaction Response Time(Distribution)（事务响应时间(分布)）“事务响应时间(分布)”显示在场景运行过程中，事务执行所用时间的分布，通过它可以了解测试过程中不同响应时间的事务数量。如果系统预先定义了相关事务可以接受的最小和最大事务响应时间，则可以使用此图确定服

11、务器性能是否在可以接受的范围内。Web Resources（Web资源分析）Web资源分析是从服务器入手对Web服务器的性能分析。1、Hits per Second（每秒点击次数）“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。2、Throughput（吞吐率）“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位

12、是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。“吞吐率”图和“点击率”图的区别：“吞吐率”图，是每秒服务器处理的HTTP申请数。“点击率”图，是客户端每秒从服务器获得的总数据量。3、HTTP Status Code Summary（HTTP状态代码概要）“HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状态代码数，该图按照代码分组。HTTP状态代码表示HTTP请求的状态。4、HTTP Responses per Second（每秒HTTP响应数）“每秒HT

13、TP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回其它各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。5、Pages Downloader per Second（每秒下载页面数）“每秒下载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。使用此图可依据下载的页数来计算Vuser生成的负载量。和吞吐量图一样，每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。但是吞吐量考虑的各个资源极其大小（例，每个GIF文件的大小、每个网页的大小）。而每秒

14、下载页面数只考虑页面数。注：要查看每秒下载页数图，必须在R-T-S那里设置“每秒页面数(仅HTML模式)”。6、Retries per Second（每秒重试次数）“每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。在下列情况将重试服务器连接：A、初始连接XXB、要求代理服务器身份验证C、服务器关闭了初始连接D、初始连接无法连接到服务器E、服务器最初无法解析负载生成器的IP地址7、Retries Summary（重试次数概要）“重试次数概要”显示场景或会话步骤运行过程中服务器尝试的连接次数，它按照重试原因分组。将此图与每秒重试次数图一起使用可以确定场景或会话步骤运行过程中服务

15、器在哪个时间点进行了重试。8、Connections（连接数）“连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。借助此图，可以知道何时需要添加其他连接。例：当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）。9、Connections Per Second（每秒连接数）“每秒连接数”显示方案在运行过程中每秒建立的TCP/IP连接数。理想情况下，很多HTTP请求都应该使用同一连接，而不是每个请求都新打开一个连接。通过每秒连接数图可以看出服务器的处理情况，就表明服务器的性能在逐渐下降。10、SSLs Per Second（每秒

16、SSL连接数）“每秒SSL连接数”显示场景或会话步骤运行的每一秒内打开的新的以及重新使用的SSL连接数。当对安全服务器打开TCP/IP连接后，浏览器将打开SSL连接。Web Page Breakdown（网页元素细分）“网页元素细分”主要用来评估页面内容是否影响事务的响应时间，通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的元素。1、Web Page Breakdown（页面分解总图）“页面分解”显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。“页面分解”图可以按下面四种方式进行进一步细分：1)、Download Time Breaddown（下载时间细

17、分）“下载时间细分”图显示网页中不同元素的下载时间，同时还可按照下载过程把时间进行分解，用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。2)、Component Breakdown(Over Time)（组件细分(随时间变化)）“组件细分”图显示选定网页的页面组件随时间变化的细分图。通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。3)、Download Time Breakdown(Over Time)（下载时间细分(随时间变化)）“下载时间

18、细分(随时间变化)” 图显示选定网页的页面元素下载时间细分（随时间变化）情况，它非常清晰地显示了页面各个元素在压力测试过程中的下载情况。“下载时间细分”图显示的是整个测试过程页面元素响应的时间统计分析结果，“下载时间细分(随时间变化)”显示的事场景运行过程中每一秒内页面元素响应时间的统计结果，两者分别从宏观和微观角度来分析页面元素的下载时间。4)、Time to First Buffer Breakdown(Over Time)（第一次缓冲时间细分(随时间变化)）“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一次缓冲之前的这段时间，场景或会话步骤运行的每一秒中每个网页

19、组件的服务器时间和网络时间（以秒为单位）。可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。First Buffer Time：是指客户端与服务器端建立连接后，从服务器发送第一个数据包开始计时，数据经过网络传送到客户端，到浏览器接收到第一个缓冲所用的时间。2、Page Component Breakdown（页面组件细分）“页面组件细分”图显示每个网页及其组件的平均下载时间（以秒为单位）。可以根据下载组件所用的平均秒数对图列进行排序，通过它有助于隔离有问题的组件。3、Page Component Breakdown(Over Time)（页面组件分解(随时间变化)）“页面组件分

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

21、时间细分(随时间变化)”图显示方案运行期间，每一秒内每个页面组件下载时间的细分。使用此图可以确定网络或服务器在方案执行期间哪一时间点发生了问题。“页面组件细分(随时间变化)”图和“页面下载时间细分(随时间变化)”图通常结合起来进行分析：首先确定有问题的组件，然后分析它们的下载过程，进而定位原因在哪里。6、Time to First Buffer Breakdown（第一次缓冲时间细分）“第一次缓冲时间细分”图显示成功收到从Web服务器返回的第一次缓冲之前的这一段时间内的每个页面组件的相关服务器/网路时间。如果组件的下载时间很长，则可以使用此图确定产生的问题与服务器有关还是与网络有关。网络时间：

22、定义为第一个HTTP请求那一刻开始，直到确认为止所经过的平均时间。服务器时间：定义为从收到初始HTTP请求确认开始，直到成功收到来自Web服务器的一次缓冲为止所经过的平均时间。7、Time to First Buffer Breakdown(Over Time)（第一次缓冲时间细分(随时间变化)）“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一个缓冲之前的这段时间内，场景运行的每一秒中每个网页组件的服务器时间和网络时间。可以使用此图确定场景运行期间服务器或网络出现问题的时间点。8、Downloader Component Size(KB)（已下载组件大小）“已下载组件

23、大小”图显示每个已经下载的网页组建的大小。通过它可以直接看出哪些组件比较大并需要进一步进行优化以提高性能。1.1问题集1.1.1LR-29976项目名称：京华网络测试问题描述：网络测试的时候，用loadrunner遇到一个报错Action.c(15): Error -27796: Failed to connect to server 10.2.4.112:80: 10061 Connection refused问题原因：查找错误代码LR 2887610061的具体含义，原因是服务器和客户端的通信出现丢包现象。解决方法：1.由于同事说无法远程，所以根据网上的解决方法进行设置：A尝试修改注册表中

24、HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters里，有如下两个键值：TcpTimedWaitDelayMaxUserPort端口等待时间调小，最大可用端口调大B把360和防火墙关闭C尝试把tomcat配置中的connectiontimeout时间和account也调一下2.以上方法无法解决，我觉得很奇怪，因为他们说并发数只是5，所以我坚持要查看他们的脚本。后来通过回放脚本发现他们的脚本有问题。A脚本中登录放在int中，然后对登录账号进行了参数化；B插入了事务，但是没有插入集合点；后来，把登录放到action中，同时

25、添加集合点，问题得以解决。原因：个人认为，主要是登录放在int中并进行参数化引起的问题。因为，参数化会有个迭代的问题，但是，迭代不会重复跑int中的脚本，所以出现此问题。3.此问题，在交易所的竞价系统性能测试也遇到过，但当时是并发数为500时才出现的问题。这个问题，当时没有解决，因为个人认为是测试机自身的问题。因为据了解一台客户机一般最多并发150用户（2GB内存）。所以，相同的问题，会有不同的原因，还得具体情况具体分析。1.1.2多台负载机并发测试项目名称：增量指标竞价管理系统平台问题描述：该平台，要求的并发数达到万级，所以，单个笔记本无法完成施压工作。问题原因：笔记本自身配置问题解决方法：

26、采用多台负载机并发测试。具体做法：以笔记本作为主控机，客户提供的多台PC机作为负载机，在PC机上安装LoadGenerator，然后在主控机上连接负载机同时跑多个相同的脚本，达到模拟脚本在各负载机上运行的效果。但是，当时由于PC机都是win7操作系统，由于LR跟win7兼容性不好，所以经常会出现主控机和负载机断开的现象，所以，此方法当时无法解决并发数达到万级的施压工作。不过，如遇到大并发量的时候，应该要想到此方法。1.1.3ApachBench工具项目名称：增量指标竞价管理系统平台问题描述：该平台，要求的并发数达到万级，所以，单个笔记本无法完成施压工作。问题原因：笔记本自身配置问题解决方法：利

27、用ApachBench工具完成了此次的负载测试。Apache服务器自带有一个叫AB(ApacheBench)的工具，在bin目录下。使用这个轻巧的工具可以对服务器进行负载测试。基本用法:ab -n全部请求数-c并发数测试url问题得到解决，但是，此处的并发数跟请求数有什么关系？此处的并发是如何进行并发的？此处的一个并发是否是对服务器的一次请求？等等，我有些疑问，网上资料比较少，疑问还没解决，求教。1.1.4Sitescope的使用背景：服务器是windows 2008操作系统，做性能测试时用LR使用windows server2003的监控方法监控不到服务器，没有报错，就是LR没有显示数据。由

28、于当时服务器上的administrator用户被删除，所以个人认为有可能是这个原因。具体原因有待查找。思路：由于监控不到服务器，当时就想到利用其他监控工具，具体用什么工具呢？当时就想着能跟LR联合起来使用的，这样方便我们整理报告。于是查看了LR中的system resource graphs中的每一项。Windows resource和linux resource项大家都比较熟悉，server resource是监控一些具体服务的，譬如webserverresource的apache和MS IIS，不合适。SNMP是一种网络协议，应该是用于监控网络的，也不适用。Sitescope能够监视超过6

29、5种危及的健康和性能的特性，如利用率、响应时间、占用率和可用资源等，允许设置阀值(threshold)在问题产生前发送预制的警告信息，觉得适用，所以决定使用sitescope监控工具。实践：第一步：在服务器上安装sitescope9.5，然后通过本机运行sitescope，第二步：右击sitescope，新建组第三步：右击新建的组，选择新建监控器填写相关的信息后，去掉仅显示配置的服务器项，点击获取服务器，然后在服务器下拉框中选择要监控的服务器。注意：1.名称不能是中文；2.频率最少是15s添加成功后可以看到监控器的实时数据第四步：LR添加系统监控场景设计，添加sitescope，然后右键点击a

30、dd measurements注意：1.添加完machine后，还要添加具体的监控器，图中的1、22.当sitescope中的组名用中文时，LR无法添加监控，可能是因为LR跟中文的兼容性不够好。1.1.5LR监控windows 2008操作系统问题描述：基于工商联项目，LR监控不到windows 2008操作系统，当时由于系统超级管理员administrator用户被删除 解决方法：Windows20008的监控跟windows server2003的监控方法一样。但要使用administrator用户访问服务器网络共享。具体方法如下：1、通过客户端与服务器进行网络测试，保证通信畅通2、开启服

31、务器端Windows中的Remote Procedure Call (RPC)和Remote Registry两个服务，如下图：需要对服务器的系统本地策略进行更改，这个很重要，也是决定客户端能不能访问服务器端的关键步骤，具体需要进入控制面板下的管理工具中，找到本地策略中的安全策略，在右侧找到“网络访问：本地账户的共享和安全模式”并双击它。如下：在弹出的对话框中选择“经典-本地用户以自己的身份验证”。如下图：“我的电脑”右键，“管理共享文件夹共享”：查看右侧是否有C$文件，若没有自己创建一个。如下图：在地址栏输入服务器IPC$（如192.168.1.177C$），出现服务器端的C盘内容。此时证明可以连接到Windows服务器了。如下图