LoadRunner Controller 中，Run Logic 和 Pacing 共同定义了每个虚拟用户做什么、做多少次，以及以怎样的节奏去做。理解两者怎样配合，是设计精确性能场景的重点。

一、Run Logic控制做什么、做几次

Run Logic设置在Runtime Settings的Run Logic选项卡下，负责定义脚本中 Action 部分的迭代次数和执行顺序。

迭代次数：指定Action重复执行的次数。如果场景设为Run until completion，Vuser 会跑完指定迭代后停止；如果场景设为Run for a specific duration，则迭代次数一般设为一个很大的值，让 Vuser 在整个不断时间内不断循环。

Action 执行顺序：当脚本包含多个 Action（如 Login、Browse、Logout）时，可在此设置为顺序执行、随机执行或按百分比分配，让同一个脚本模拟出不同的业务流程。

Init/Action/End 的职责划分：vuser_init 和 vuser_end 各自只执行一次，Run Logic 只管中间 Action 的循环次数，不受初始化和清理的影响。

Run Logic是脚本的循环计数器，解决一个Vuser要重复几次业务这个问题。

二、Pacing-控制多久做一次

Pacing位于Runtime Settings的Pacing选项卡，决定两次迭代开始之间的时间间隔，而不是迭代内部每一步的间隔。

Pacing 提供三种方式，行为差别显著：

As soon as the previous iteration ends

上一次迭代结束后立即开始下一次。此时迭代开始间隔等于单次迭代的实际执行时长（含思考时间）。Vuser 会以最快速度不断施压，适合极限压力测试或寻找最大 TPS。

After the previous iteration ends（可加固定或随机延迟）

上一次迭代结束后，再等待指定延迟，然后开始新迭代。真实迭代开始间隔 = 单次迭代耗时 + 延迟时间。如迭代跑了 5 秒，设置延迟 10 秒，则两次迭代开始间隔为 15 秒。它模拟的是完整业务流程结束后的休息时间，和迭代内部的思考时间不同（思考时间在迭代内，Pacing 在迭代间）。适合模拟真实用户带有业务间停顿的场景，加上随机延迟会更自然。

At fixed / random intervals

不管上一次迭代实际跑了多久，都严格按固定或随机的时间间隔发起下一次迭代。如果一次迭代耗时小于间隔，Vuser 会等到间隔到达再开始；如果一次迭代耗时已经超过间隔，则结束后立即开始下一次（不会“补回”等待）。这种方式可以极其精确地控制每个 Vuser 的请求率。如，固定间隔 15 秒，每个 Vuser 每小时必定完成 240 次迭代，从而让总吞吐量完全可算。

怎样根据目的选择 Pacing 方式

如果目的是极限压力或最大吞吐量，应使用 As soon as the previous iteration ends，让 Vuser 不间断运行。

如果目的是模拟真实用户带有业务间停顿，推荐使用 After the previous iteration ends，并可附加随机延迟来增强真实性。

如果需要严格控制每个 Vuser 的固定请求率，则选择 At fixed intervals 或 At random intervals，使每个用户的迭代节奏完全服从设定间隔。

三、Run Logic和Pacing的协同场景设计中的计算

两者的组合决定了整个场景的负载曲线。

Run until completion方式下总时长估算：

总时长 ≈ 迭代次数 ×（单次迭代平均耗时 + Pacing 延迟）。

如果使用固定间隔且间隔大于迭代耗时，则可简化为 总时长 ≈ 迭代次数 × 间隔值。

按不断时间（Duration）运行时的 TPS 控制：

每个 Vuser 每秒完成的迭代数 = 1 / max(迭代实际耗时, Pacing 间隔)。

总 TPS = Vuser 数 × 该值 × 每次迭代包含的事务数。

因此，通过调整 Pacing（尤其固定间隔），可以在不改变 Vuser 数量的前提下精确调节系统负载，非常适用于长时间稳定性测试。

组合：

突发并发：迭代次数设为 1，Pacing 设为 As soon as possible，大量 Vuser 同时执行一次迭代（常配合集合点使用）。

匀速加压：场景不断时间 1 小时，Pacing 设为固定间隔 30 秒，Vuser 数固定，则系统每秒接收到的请求数稳定不变，适合测试长期稳定性。

真实用户波动模拟：使用随机迭代次数 + 随机 Pacing（After iteration 方式），再配合随机思考时间，能够模拟访问节奏的自然变化。

四、误区和实践

混淆 Pacing 和 Think Time：Think Time 位于迭代内部，模拟操作间的停顿，会延长单次迭代的响应时间；Pacing 位于迭代之间，控制的是新迭代的发起节奏，它不改变单次迭代的服务端响应时间，但改变请求的时间分布。

误认为设了 Duration 就必须将迭代次数设为无限：如果业务本身就有限次（如“每个用户只做 5 次查询”），完全可以在 Duration 内让 Vuser 跑完固定迭代后停止，剩余时间 Vuser 进入 Waiting 状态，这更贴近真实用户行为。

固定间隔设得过小：如果设置的固定间隔小于绝大多数迭代的实际耗时，则 Pacing 失效，实际效果等同于“As soon as possible”。要想有效限流，间隔应大于迭代耗时的 95% 分位值。

调试时忽略 Pacing 的影响：脚本开发阶段常用“As soon as”快速证实，但设计正式场景时必须重新考虑 Pacing 取值，否则会把调试时的非真实压力模型带入测试，导致结果偏离实际。

Run Logic管循环几次，Pacing 管多久一循环。 将两者和 Vuser 数量、场景计划（Schedule）结合，就组成了对系统施加负载的完整定义。把握住这两点，性能场景设计才能从随意压测进阶为精确控压。