当压力测试的并发用户数逐渐增加时，负责产生负载的机器有时会先成为性能瓶颈。LoadRunner的负载机应该如何分配才能更合理，分配不均匀又会导致哪些问题，这需要结合脚本所用的协议、虚拟用户的数量、负载机的硬件配置以及网络位置等条件来综合判断。在LoadRunner中，Controller会把Vuser分派到各个负载机上执行，一台负载机能够同时运行多个不同类型的Vuser脚本，所以在正式测试开始之前，应当确保每台负载机都留有足够多的处理能力。

　　一、更合理的负载机分配方法

　　对负载机进行分配，并不是简单地将并发用户数量平均分摊下去就完事了，因为基于HTTP协议的接口脚本、GUI脚本以及那些依赖特定客户端环境的脚本对资源的消耗差异非常大，所以首先应当按照协议类型和业务功能将脚本划分成不同的小组。

　　1、先把手工场景建起来

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

　　2、依据脚本的类型去拆分负载机

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

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

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

　　4、管好Controller自身的负载

　　假如条件允许，最好把Controller和负载机分别部署在不同的物理机上，官方在快速入门文档里也提醒过，当Controller和负载机都要承担比较重的任务时，推荐将它们分开到不同的主机上，这样可以防止调度端和压力产生端彼此干扰。

　　二、负载机分配不均匀所带来的后果

　　负载机分配不均匀，带来的影响不仅仅是某一台机器运行速度变慢而已，情况严重时，它会搅乱整个加压的节奏，让响应时间指标失真，甚至增加错误率，最终让测试得出的结论失去参考意义。

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

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

　　2、响应时间可能会被负载机拖高

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

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

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

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

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

　　三、怎样对负载机的状态进行复核

　　负载机的分配工作结束之后，在正式开始压测之前还需要再执行一次验证，不能仅仅因为界面上看到每台机器都显示了Ready状态，就想当然地认为所有配置都没有问题。

　　1、检查各个机器的连接状态

　　首先，去点击Controller工具栏里面的【Load Generators】按钮，确认每一台机器都已经成功连接，并且它们的状态已经从Down转成了Ready，对于那些暂时不参与本轮测试的机器，直接把它停掉即可，不必从场景里彻底删除。

　　2、做一段短时间的试跑

　　接下来，先用较低的并发用户数跑上大概十分钟的时间，然后查看每一台负载机上各自运行了多少Vuser、这些Vuser的启动速度如何，以及有没有出现失败的状况；如果发现有某台机器的负载明显比别的机器更重，就回到场景设计里重新调整各个用户组的分配。

　　3、持续观察CPU和网络的情况

　　在运行过程中，要持续地去观察负载机的CPU状态，同时也需要留心网络带宽的占用、磁盘的写入速度以及产生的日志量；如果日志的级别设得过高，也会给负载机增加额外的压力，所以在正式压测前应该把一些无关紧要的日志关掉。

　　4、把分配记录保留下来

　　最后，把这一次测试的场景名称、脚本版本、负载机机器的名字、硬件配置、Vuser的数量以及测试的时间点都记录下来，等到后面分析结果时，万一出现数据波动，就可以先排查是不是施压环境本身发生了变动，而不是一上来就把问题全都归到被测的业务系统头上。

　　总结

　　概括起来，LoadRunner中负载机的分配可以遵循这样一个顺序：先把脚本按照类型和协议分组，然后逐步地增加压力，最后再对各项资源进行复核。如果分配得不均匀，就可能会引发Vuser加载失败、响应时间失真、业务比例出现偏差，甚至导致测试意外中断；因此，在正式测试前先做一次低并发的试跑，同时把负载机的状态和分配记录都完整地保存下来，这样后续的分析工作才会更加扎实可靠。