1.Runtime setting的设置

  *Think time

 这个就不多说了，如果忽略则"响应时间"会变短，但同时对服务器的压力增大，从而间接影响响应时间

在anlaysis里有个过滤设置，可以设置过滤掉Thinktime，没有详细研究过

 

* Pacing设置

 这个是我们经常忽略的一个设置

 xinqidian123在他的空间的文章里提到：

其实LoadRunner是以客户端的角度来定义“响应时间”的，当客户端请求发出去后，LoadRunner就 开始计算响应时间，一直到它收到服务器端的响应。这个时候问题就产生了：如果此时的服务器端的排队队列已满，服务器资源正处于忙碌的状态，那么该请求会驻 留在服务器的线程中，换句话说，这个新产生的请求并不会对服务器端产生真正的负载，但很遗憾的是，该请求的计时器已经启动了，因此我们很容易就可以预见 到，这个请求的响应时间会变得很长，甚至可能长到使得该请求由于超时而失败。等到测试结 束后，我们查看一下结果，就会发现这样一个很不幸的现象：事务平均响应时间很长，最小响应时间与最大响应时间的差距很大，而这个时候的平均响应时间，其实 也就失去了它应有的意义。也就是说，由于客户端发送的请求太快而导致影响了实际的测量结果，设置步长则可以缓解这一情况，这样，应该试试设置pacing，再运行看看情况。

2.场景的设置

加载和释放虚拟用户的设置

如果在比较短的时间间隔加载较多的vuser，无疑会对加载过程中的服务器产生较大压力，从而使总的平均响应时间变长

有时我们会发现一个有点费解的现象，在场景停止的最后时间，响应时间图的曲线会呈上升状态

在论坛里看到有同学提出这样的疑问，有回复提到：

如果在高负载的系统中运行，会话线程执行完后一直没有释放的话，那么就会造成后者请求线程一直在等待前者运行线程的结束，那么响应时间自然而然的就增加了。类似于Pacing设置的说明

个人觉得，和释放vuser的设置应该也有一定关系，希望各位来探讨下

 

 

1.在看这篇文章之前我想大家首先要对LR有一定的了解，你要知道以下这些内容：

　　1)LR中是通过Transaction进行响应时间统计的，Transaction是一组函数，可以在测试脚本中根据我们要衡量的业务响应时间进行定义，要是大家不了解可以参见我写的一篇关于LR事物的专题：

 

　　2)LR结果分析中给出的响应时间有：最大、平均、最小、标准差、90%几种，另外包括一个事物平均响应时间的曲线。

 

　　3)LR的响应时间的统计是基于事物的，这些数据可以在结果分析中得到。

 

　　4)最好你对Excel中的函数不陌生

 

　　2.那么LR结果分析中如何获得这些响应时间的呢?下面我们开始介绍：

 

　　1)首先LR以时间位移为基准收集所有事物的响应时间，收集的这些数据作为分析的基础。

 

　　2)将上述收集的信息进行统计得到最大、平均、最小、标准差、90%的响应时间。以及画出事物平均响应时间的曲线。

 

　　3)平均响应时间：在事物全部响应时间做平均计算;

 

　　4)最大响应时间：在事物全部响应时间中求MAX

 

　　5)最小响应时间：在事物全部响应时间中求MIN

 

　　6)标准差：在事物全部响应时间数据中做标准差运算

 

　　7)90%响应时间：将事物全部响应时间进行排序然后求90%数据中的最大值;

 

　　8)事物平均响应时间曲线，曲线中点的个数跟取样时间(可设定)和测试运行时间相关(当然选取的数据是可以设定的，在结果分析过程中可以选择抽取那段时间的数据);每个点数据的计算是根据：在采样时间范围内所有事物响应时间的平均。

 

　　3.如何验证上述的情况是对的呢?大家可以用以下的方法：

 

　　1) 设置一个LR的测试场景，运行获得结果数据;

 

　　2) 打开结果分析工具，获得测试结果;

 

　　3) 然后将LR中统计的所有数据导入到Excel中进行手动分析(具体步骤不说了);

 

　　4) 通过EXCEL中的数据统计功能，统计最大、最小、平均、标准差(可以去网上查他的含义，我不想说，这是数学)、90%的响应时间，然后跟LR结果分析中给出的数据进行比较，你就能验证你的想法。

 

　　这些东西什么用?你可以说他很有用，当然对于你也可能没有用，而只看一个热闹，那么对于所有看热闹的人来说就当一个乐子吧，对于有用的人来说，你就来着了，具体更深的细节我们可以再讨论。