目录

一、LR中各项疑问

二、LR中脚本相关

三、LR中遇到的问题

 

 

一、LR中各项疑问

1.1、web_url函数中的Resource参数和RecContentType参数

RecContentType表示录制对象的MYME type
Resource表示该对象是否是Non-HTML Resource。

录制选项

设置路径：
Recording Options->Advanced->Content-types
如果录制对象的MYME type包含在录制选项中允许录制的content-type中，则该操作可以被录下来，反之则不能

设置路径：
Recording Options->Advanced->Non-Resources
录制时，包含在Non-Resources列表中的MYME type对应的Resource会被设置为0，其它类型的对象均被设置为1

 

回放选项

设置路径：
Run-time settings->Browser Emulation->Download non-HTML resources
当Resource为0时，表示URL对象不是Non-HTML Resource，重放时该对象总会被下载；当Resource为1时，表示URL对象是Non-HTML Resource，只有设置Download non-HTML resources后，在重放时该对象才会被下载

设置路径：
Run-time settings->Perferences->Non-critical item errors as warnings
设置下载Resource =1的资源时出现的错误作为warnings

1.2、return 0

验证代码：

int c=0;
      Action()
      {

　　　　c=c+1;
　　　　if(c==3)
　　　　{
　　　　　　return 0;//注释这个后又会发生什么？
　　　　}
　　lr_output_message("sum=%d",c);
　　return 0;
　　}

return 0 的意思是：结束本次迭代，然后进行下次迭代。

return -1的意思是：结束本次迭代，然后停止执行。

1.3、思考时间

思考时间：lr_think_time 就是一个事务要开始时思考的时间。

思考时间的意义？更真实的模拟用户的行为。一般思考时间都设在两个事务之间。

思考时间对性能的影响？前提：服务器没有达到瓶颈，还有处理能力或处理能力无限时。加上思考时间会降低服务器压力（即降低用户并发量），减少服务器的TPS。

 

下面详细介绍一下思考时间在LR中的使用。

1）virtual user generator（脚本录制与设置）

　　a、在录制脚本的时候LoadRunner会自动记录录制者在录制软件系统时实际操作的思考时间，并在系统中以lr_thingk_time(x);函数表现。这里的思考时间如登录操作：LoadRunner打开了登录界面后开始记录思考时间，包括录制者输入用户名，密码；或去干其他事。直到录制者点击登录按钮，整个这段时间都被LoadRunner记录为思考时间。

　　b、回放录制脚本时，在Vuser->Run-time Setting->Think Time设置回放脚本时思考时间的使用。

      lgnore think time：忽略脚本中的思考时间。

      As recorded：根据脚本中实际的思考时间进行回放。

      Multiply recorded think time by：将录制的思考时间乘以一个系数，系数在后面设置。

      Use random percentage of recorded think time：随机获取思考时间，指定一个最小值和一个最大值，可设置Think Time值的范围，通过指定Think Time的范围，取其中的一个随机数的值来回放脚本。

　　例如，如果Think Time参数为4，并且指定最小值为该值的50%，而最大值为该值的150%，则Think Time的最小值为2（50%），而最大值为6（150%）。

              Limit think time to：忽略脚本中的思考时间，执行这里设置的思考时间。

注意：如果这里不对思考时间进行设置，也就是默认忽略思考时间的话只影响回放脚本时操作，不影响场景执行的时候。只有对思考时间进行了设置，场景执行时才会有效。

2）Controller（场景设置与执行）

　　场景设置中没有对思考时间的设置，如果在脚本设置中设置了思考时间那么场景会按设置的思考时间执行，如果脚本设置中默认忽略思考时间，那么在执行场景时LoadRunner会默认按录制时的思考时间执行，事务响应时间中包括了思考时间。

3）Analysis（结果分析）

a、结果分析中可以对思考时间进行设置，是否在事务响应时间中添加思考时间或是去掉思考时间。

b、设置是否计算思考时间：File->set Global Filter中选择Think Time设置项，将lnclude think time值去掉勾选。

这样分析中会自动将思考时间去除，这样更清楚，明确的分析系统事物的响应时间。

1.4 tps 与 事务平均响应时间关系对答

在网上看到一篇文章，tps 与 事务平均响应时间关系对答。可以帮助能更清楚的了解二者之间的关系。

 

问者：每秒处理的事务数和事务的平均响应时间 怎么个关系，有关系吗 

kaku21：举个例子：一个高速路 有10个入口，每个入口每秒钟只能进1辆车，请问1秒钟最多能进几辆车？？ 

问者：10 

kaku21：每辆车需要多长时间响应？？ 

问者：针对这个问题的话 那tps就是10 ，事务的响应时间是1 

kaku21:好，那现在我有20辆车，那每秒能进几辆？？每辆响应时间是多少？？ 

问者：。。。思考中        

kaku21:每秒还是进10辆车呗，每辆车还是1秒响应啊 

问者：对呀 

kaku21:继续，现在我把入口扩展到20个，那我问你，每秒最多进多少辆车？？每辆车响应多长时间？？ 

问者：20  1 

kaku21:好，现在tps变了，响应时间没变，那我问你 tps跟响应时间有啥关系？？ 

问者：没关系 

kaku21: tps和响应时间在理想状态下都是额定值，你把入口看做线程池。如果20个入口，并发数只有10的时候，tps就是10，而响应时间始终都是1，说明并发不够，需要增加并发数达到tps的峰值。 

问者：同样是20个入口，并发数是100的话，tps是20，响应时间还是1？ 
什么情况下响应时间会大于1秒 

kaku21:我问你，当并发数量是100的时候，会出现什么情况？？ 

问者：堵车啦。。。哦，堵车了 平均每个车过去的时间就长了？ 

kaku21:堵车说白了就是有车在等待，现在把100按20分成5份，第5份等待的时间是最长的，从等待开始到这个车进去，实际花费了多长时间？？ 

问者：5秒吧 

kaku21:那么100两车的平均响应时间是多少？？ 

问者：5除以100？0.05？ 

kaku21:错，用简单的数学逻辑算 (5+4+3+2+1)/5=3 这就是平均响应时间 

明白没？？接着问你，100两车的平均tps是多少？？ 


问者：20？ 

kaku21:错(20/1+20/2+20/3+20/4+20/5)/5 约等于 8.8999 

问者：前面tps还是20呢 ，并发大了 怎么tps小了.20是tps的峰值？ 

kaku21:响应时间和TPS在宏观上是反比的关系，但是两者之间没有直接关系 

kaku21:20是一次并发的数量，100的并发则造成了线程的等待，引起平均响应时间从1秒变成3秒，当然TPS也从20下降到9;TPS和响应时间都是单独计算出来的，两者不是互相计算出来的。

1.5、 LR的pacing设置

LR中设置pacing值有三种策略。经常用于进行tps的调整。 

Iteration，迭代。通过设置，可以指定虚拟用户在同一个Action中重复执行多次，每次重复称之为一个iteration。Iteration可以帮助我们模拟现实世界的重复场景。

Pacing，步调。可以通过设置两次迭代之间的间隔时间，来调整各个action之间的步调（或者称之为节奏）。从定义上来看，Pacing是和iteration绑定在一起的，可以认为是iteration pacing。

 

 具体策略：

lua项目目录 lr 目录_ci

第一项：每次迭代之间无间隔时间。 

第二项：每次迭代之间设置固定的间隔时间。即当上次迭代结束后,等待一定时间再进行下次迭代。

lua项目目录 lr 目录_响应时间_02

lua项目目录 lr 目录_响应时间_03

从图上，可看出分fixed模式与random两种模式。

fixed即取后边设置的固定时间。

random则事先设置一个范围，取值时随机从范围里取值。

 

第三项：较为复杂。

从上一次迭代开始到本次迭代开始的时间。

lua项目目录 lr 目录_迭代_04

此时和响应时间的关系是：

lua项目目录 lr 目录_响应时间_05

这种模式的时候理想情况下  TPS = 1/pacing 值

此种设置要保证pacing值大于>action时间。

 

如何获取action时间？

1.   action执行时间 和 业务时间 和响应时间的区别?

   业务时间 是从lr_start_transaction  到 lr_end_transaction的时间

   action执行的时间 粗略的说是整个脚本的执行时间(涵盖业务时间)

  响应时间 = 业务时间 +传输时间+服务器损耗时间等多种 通常情况下我们认为 响应时间=业务时间

2. 如何计算action时间?

   (1)  注释lr_start_transaction  和lr_end_transaction

   (2)  启用自动transaction

     runtime-setting中设置:

lua项目目录 lr 目录_ci_06

(3) 设置单用户、无pacing值得情况下 跑下场景，此时的action响应时间就是action时间

 

二、LR中脚本相关

1、随机参数化

int  tid;
    lr_save_int(rand()%6070,"tid");   
    lr_output_message(lr_eval_string("tid={tid}"));

 2、EXTRARES日志打印问题

在LR脚本请求里常见有EXTRARES资源类文件如gif、png、js等类型。如果这个请求步骤报错了，场景执行时想看一下请求的实际返回值。在场景执行时打开服务器返回日志，并同时增加一个关联函数，获取返回值。

问题来了：最终关联值返回的响应时主请求的响应，还是图片的响应呢？

答案揭晓：返回的是最后一个图片btbg_blue.gif的响应值，结果中以gif89a开头。将btbg_blue.gif注释后，关联响应返回crash_bg.jpg的结果。在将EXTRARES资源类文件所有都注释掉后，终于返回了主请求的返回值提示未登录成功。

如果要看请求的响应这个需要注意一下。

web_url("forwardNode.do",
        "URL=http://10.96.124.155/undwrt/bpm/forwardNode.do?",
        "Resource=0",
        "RecContentType=text/html",
        "Referer=http://10.96.124.155/undwrt/menu/showMenu.do?systemCode=undwrt&menuId=0",
        "Snapshot=t7.inf",
        "Mode=HTML",
        EXTRARES,
        "URL=../common/loading/images/loading.gif", "Referer=http://10.96.124.155/undwrt/bpm/forwardNode.do?", ENDITEM,
        "URL=../common/loading/images/block-bg.gif", "Referer=http://10.96.124.155/undwrt/bpm/forwardNode.do?", ENDITEM,
        "URL=../pages/image/crash_bg.jpg", "Referer=http://10.96.124.155/undwrt/bpm/forwardNode.do?, ENDITEM,
        "URL=../pages/image/btbg_blue.gif", "Referer=http://10.96.124.155/undwrt/bpm/forwardNode.do?", ENDITEM,
        LAST);

 3、strtok函数

/* 
使用strtok函数分割字符串 
extern char* strtok(char* string, const char* delimiters); 
*/

Action()
{
    char seqarater[]=",";//分割符变量
    char * token;//存储分割出的字符变量
    lr_save_string("1,2,3,4,5,6,7,8,9,0","str");//将字符串"1,2,3,4,5,6,7,8,9,0"存入参数str中
    token=(char*)strtok(lr_eval_string("{str}"),seqarater);//用lr_eval_string取得参数str中的值，调用strtok函数分理处第一个字符1
    while(token!=NULL)//如果token中非空
    {
        lr_error_message("%s\n",token);//打印token取得的值
        token=(char*)strtok(NULL,seqarater);//取下一个字符
    }
    return 0;
}

 

三、LR中遇到的问题


1、进程执行还是线程执行  

某些时候用进程跑场景的时候tps死活上不去,而用同样数量的线程跑的时候，TPS开始很高，然后很快的跌倒谷底。当遇到这个问题时往往就是lr成为瓶颈了！

解决方法：使用多台loadrunner使用进程方式，使用之前单台lr的并发数，看看TPS是不是上涨了不少？

原因：发生此种情况一般都有一个特点，就是响应时间特别短！如果你的被测应用响应时间<10ms的时候就要小心了...

 

2、是否loadrunner对于URL中加密的参数/值对兼容性有问题？

 使用lr压测一个项目的时候,发现TPS波动巨大、且平均值较低。使用jmeter压测则没有这个问题。

web_submit_data("aaa", 
        "Action=http://demo.ddd.com/aaa?a=xr23498isfgljfsfd&b=adfasdfoi4308askdfjkla", //此处为密文链接
        "Method=POST", 
        "RecContentType=text/html",     
        "Referer=http://demo.ddd.com/ccc?a=xr23498isfgljfsfd&b=adfasdfoi4308askdfjkla", 
        "Snapshot=t2.inf", 
        "Mode=HTTP", 
        ITEMDATA, 
        LAST);
将post方法调整为get方法后问题解决。

 

3、Failed to send data by channels - post message failed

问题描述： http协议,场景运行一会之后,报错! erro信息: Failed to send data by channels - post message failed.

解决方法：http://bbs.51testing.com/thread-527804-1-1.html

HTTP协议的，windows server 2008+lr11+IE7 应该没啥特殊操作，也不是每次跑都出现这个错误，之前也跑过8小时疲劳也正常出结果。
网上搜了一圈，看到个建议把controller中的Diagnotics-configure-Web Page Diagnotics默认的Enable关掉，重新试了几次倒是正常了，现在也不确定是不是真的没问题了。
估计是兼容性的问题

 

4、Server xx has shut down the connection prematurely

最近在进行一次性能测试中遇到一个问题，并发较大的时候会出现LR出现Error -27791: Server xx has shut down the connection prematurely的ERROR，然后还有同数量的失败交易，系统架构是nginx---tomcat，遂进行以下排查：

1.开启nginx的access日志，进行测试，出错时记录下LOADRUNNER通过的事务数，和access中访问记录数做比对，发现二者一致。那么LR的失败交易是因为没有成功和nginx建立连接。

2.查看/var/log/message，发现少量的TCP: time wait bucket table overflow错误，这个应该是time_wait的数量超过了系统允许的数量。