LoadRunner的思考时间怎么配置，回放的时候它又为什么会被忽略掉，这里头的重点，并不是脚本里面有没有写lr_think_time这一句，而是运行时的设置，到底有没有让它真正起作用。思考时间这个东西，是用来模仿真实用户的那种操作间隔的，像是页面之间的停顿、阅读里头的内容、填写一些信息，还有做选择的这些过程。在调试脚本的那个阶段，可以暂时不管它，可是一旦到了正式去压测的时候，要是还一直把它给忽略掉，那些虚拟的用户就会一个接一个不停地发请求，这样一来，压力的模型就很容易跑偏，跟真实业务的节奏对不上了。

　　一、LoadRunner思考时间怎么配置

　　思考时间得跟场景的目标放在一块儿去设才行，单用户调试的时候，图的是一个快速回放，到了正式做负载测试的时候，求的又是一个真实的节奏，这两种场景下面的配置，是不应该弄成完全一样的。

　　1、先去确认脚本里面有没有写上思考时间

　　先检查一下脚本里面，是不是真的有lr_think_time这个语句，录脚本那会儿，要是录制的选项里头没有把思考时间给保留下来的话，或者是后期在整理脚本的时候不小心把它给删掉了，那运行时的设置再怎么去调整，也是不会产生停顿的。思考时间通常是放在业务步骤之间的，不太建议随随便便就把它扔到事务的内部里面去，不然的话，响应时间的统计就有可能会被拉长。

　　2、去把运行时的设置给打开

　　进到【Replay】再到【Runtime Settings】里面去，在跟Think Time相关的那个页面上，把回放的方式给设置好。

　　常见的几种方式，有直接把思考时间忽略掉的、照着录制时候的值去回放、按一定的倍数去放大或者缩小、还有按录制值去随机比例回放的。在调脚本的那个阶段，可以选忽略，这样方便快速地验证关联、参数化，还有检查点这些东西；正式的场景，一般是要把思考时间给回放出来的，有必要的话再加一点随机的比例，好让用户的行为能更靠近真实的情况。

　　3、去设一个最大值的限制

　　要是录制的时候，在某个步骤上停留的时间实在是太久了，那就可以去限制一下思考时间的最大值，就比如说，录的过程中临时去查了个资料、接了个电话，结果导致某一个lr_think_time变得特别特别长，那正式压测的时候，就不应该照着原样去回放了，可以通过限制上限的这个办法，把那种异常长的停顿，给压回到一个合理的范围里面来。

　　二、LoadRunner思考时间回放时为什么被忽略

　　思考时间被忽略的时候，还真不一定就是脚本的问题，更多的情况，是Runtime Settings、Controller场景里面的配置、这个函数它所在的位置，或者是统计的那个口径没有对上。

　　1、运行的时候选了忽略

　　最常碰到的一个原因，就是Think Time的设置里面，选了Ignore think time这个选项，这么一配，虚拟用户就会把脚本里面的lr_think_time给跳过去，不去执行它，回放的时候看起来，脚本就跑得特别快。在调试的时候这么设是没问题的，但是压测以前，就要记得把它给改回去，改成按录制的值，或者是按比例来回放。运行时的设置，可以在VuGen里面用Replay菜单把它给打开，快捷键也是可以直接进到相关的设置页面里去的。

　　2、Controller把设置给覆盖掉了

　　在VuGen里面设的是对的，这可不代表到了Controller里面就一定能生效，脚本被放进场景了以后，Controller它有可能会用自己的一套运行时设置，或者是场景里面保存的还是旧的配置。要是碰到回放时的表现，跟单机调试的时候不一样，就得去Controller里面重新查一下脚本的Runtime Settings，确认一下Think Time没有被覆盖掉。

　　3、事务的位置会影响统计

　　要是lr_think_time被写在了事务的内部里面，那事务的响应时间就可能会把这段停顿给包含进去；要是写在了事务的外面，响应时间就不会包含它，回放的时候“被忽略掉”和“没有被算进事务的时间里面”，这两个可不是同一码事。在做性能分析的时候，要先弄清楚思考时间到底有没有被执行，然后再去判断响应时间的统计里面，是不是包含了它。正式的场景里面，一般是不建议把用户思考的这段时间，给放进核心事务的计时里面去的。

　　三、思考时间配置怎么更接近真实压测

　　思考时间的配置，它不只是为了让脚本跑得慢一点而已，而是要让并发的节奏、请求之间的间隔，还有给到服务器的压力，都更接近真实的用户。配置得太小了，会把系统压得太猛，可要是配置得太大了，又可能会把压力给低估了。

　　1、结合业务的节奏去设

　　不一样的业务步骤，思考时间也应该是不一样的，登录以后去查看首页，停顿的时间可能就短一些，去填写表单的时候，停顿的就会长一些，到了确认订单的那一步，可能又会有一个更加明显的阅读和做选择的时间。不要给所有的步骤，都统一去写一个固定的秒数，这样弄出来的用户模型，会显得特别假。

　　2、配合Pacing一块儿去看

　　Think Time这个东西，管的是用户操作步骤之间的那个停顿，Pacing管的则是一次完整的迭代跟下一次之间的间隔，这两个东西，都会影响到吞吐量。要是光去调那个思考时间，却不看Pacing是怎么设的，就有可能出现单次业务的节奏看着是合理的，可是整体的循环频率，却要么过高，要么过低的情况。

　　3、正式跑之前，先做一个小场景的验证

　　正式压测以前，可以先拿少一点的虚拟用户去跑上一轮，观察一下事务的耗时、每秒的请求数、吞吐量，还有迭代的次数，这些是不是符合之前的预期。要是把思考时间给忽略掉了，压力就会很明显地变得更加密集；在大规模的负载测试里面，通常是不建议把思考时间给忽略掉的，因为它代表着真实用户操作的那种间隔。

　　总结

　　LoadRunner的思考时间怎么配置，回放的时候它又为什么会被忽略掉，可以照着“先去确认脚本里面真的有lr_think_time，再去检查Runtime Settings的设置，最后去核对Controller和事务所在的位置”这么一个顺序来处理。调试的阶段，可以临时把思考时间忽略掉，但到了正式压测的时候，就要结合业务的节奏、随机的比例，还有Pacing一块儿去配置好。回放不正常的时候，重点要去查一下，是不是选了Ignore think time这个选项、Controller是不是把设置给覆盖掉了、思考时间是不是被放在了事务的内部，以及统计的口径，是不是理解对了。