loadrunner负载机如何分配合理，分配不均会导致出现哪些问题，都需要结合脚本所用的协议、虚拟用户的数量、负载机的硬件配置以及网络位置等条件来综合判断。在loadrunner中，Controller会把Vuser分配到各个负载机上执行，一台负载机可以同时运行多个不同类型的Vuser脚本，所以在正式测试之前，需要确保每台负载机都留有足够多的处理能力。

合理负载机分配方式

1. 先建手工场景

   先在Controller中创建一个手工场景，进入Design页面将需要用到的脚本添加进来，如果采用By Number模式，每一个脚本都会放入各自对应的Vuser组里，这样就能为不同的用户组单独指定虚拟用户的数量和所运行的负载机，如果选择By Percentage模式，那么虚拟用户会按照总用户数的百分比来分配到各个脚本组中

2. 依据脚本类型却拆分负载机

   像登录、查询、下单和报表这类不同功能的脚本，可以按照类型分开摆放到不同的负载机上，对于那些资源占用明显偏高的脚本，最好避免让它跟众多轻量级的接口脚本拥挤在同一台机器上；如果是GUI类的脚本，还需要考虑到桌面会话的开销，部分协议会要求Agent以进程方式运行，因此在分配时不能直接照搬普通接口脚本的做法。

3. 控制好单台机器上的Vuser数量

   在正式开展压力测试之前，应当先做一轮小规模的阶梯式加压，比如著奸提高每台负载机上的Vuser个数，并且在这一过程中持续观察及其的CPU、内存和网络状况，不可以一上来就把计划中的所有并发用户一次性全加上，当某一台负载机的CPU使用率快要达到持续高占用状态时，就要即时降低这台机器上的并发数量，或者网测试环境里再补充更多的负载机

4. 管好Controller自身的负载

   如果条件允许，最好将Controller和负载机分别部署在不同的物理机上，这样可以防止调度端和压力产生端彼此干扰

负载机分配不均结果

1. 一部分Vuser可能无法按计划启动

   一旦某台负载机的CPU出现过载，Controller就会暂停往这台机器上继续加载Vuser，同时会尝试将后的Vuser转派给同脚本组或用户组里面的其他负载机，要是此时找不到任何可用的负载机，那么整个Vuser的加载过程就会被中断

2. 相应时间可能会被负载机拖高

   当负载机的资源变得很紧张时，脚本发送请求、处理响应以及日志写入磁盘的速度都会一起变慢，这时候事务的响应时间虽然升高，但这些增加的延迟不一定全都是被测系统造成的，其中有一部分可能是施压端自身性能不足引起的

3. 业务的比例容易出现失真

   如果某个脚本只被绑定到一台负载机上，而其他脚本却分布在了多台机器上，那么只要这台唯一的机器出现过载或者网络断开的情况，它所负责的那部分业务流量就会明显减少，最终测试场景中登录、查询和下单这些操作的比例也会偏离当初的设计目标

4. 掉线会打断测试的连续性

   负载机短暂的网络中断之后，Controller通常可以尝试自动重新连接，但如果断连的状态持续了很长一段时间，那就需要由人工来重新建立连接，并且重新测试；在大型测试场景里，哪怕只有一台负载机的工作状态不稳定，都可能导致整整一轮的测试结果无法直接拿来相互比较。

以上便是关于loadrunner使用教程之负载机分配的相关内容，希望可以帮助到大家，想获取更多信息欢迎随时与我们取得联系。