1. 项目概述从“录脚本”到“测性能”的认知跃迁看到“性能测试loadrunner2”这个标题很多刚接触性能测试的朋友可能会想这大概就是接着上一讲继续教怎么用LoadRunner这个工具吧。如果你也这么想那可能就错过了性能测试最核心的价值。在我过去十多年的测试生涯里见过太多团队把LoadRunner用成了“脚本录制回放器”和“并发数调节器”——脚本录好了用户数调上去跑完看看平均响应时间报告一交任务就算完成了。结果呢线上该崩还是崩瓶颈在哪依然一头雾水。这个“2”在我看来它标志着一个关键的转折点从学习工具的基本操作LoadRunner 1进阶到理解如何用工具去设计和执行一场真正有价值的性能测试LoadRunner 2。性能测试的本质不是“跑工具”而是通过工具模拟真实业务压力去探究系统在各种负载下的表现、发现其能力边界和潜在瓶颈。LoadRunner只是我们手中的“显微镜”和“压力机”而如何设计实验、如何施加压力、如何观察现象、如何分析数据才是我们真正要掌握的“实验方法”。本教程将彻底抛开“按钮点击指南”式的教学带你深入一场标准性能测试的完整闭环。我们会聚焦于LoadRunner在实战中的核心应用场景如何将零散的脚本组装成贴近真实业务的场景如何科学地设计并发模型如何监控系统资源以及最终如何从海量数据中提炼出有说服力的结论。无论你是希望验证系统容量还是排查线上慢查询亦或是做新系统上线前的性能评估这里提供的思路和实操细节都能让你直接套用。2. 性能测试核心流程与LoadRunner的角色定位在动手操作之前我们必须建立起正确的流程观。一次完整的性能测试远不止在LoadRunner Controller里点“Start Scenario”那么简单。它是一套环环相扣的工程活动。2.1 性能测试的通用流程框架一个严谨的性能测试流程通常包含以下阶段而LoadRunner在其中扮演着关键的执行与数据收集角色需求分析与模型建立这是所有工作的起点。我们需要明确测试目标是评估系统最大容量压力测试还是看系统在长时间运行下的稳定性耐力测试或者是验证在特定用户量下的响应速度负载测试基于目标我们要分析生产环境的业务数据比如用户活跃时间段、典型业务操作登录、浏览、下单的比例、每次操作之间的思考时间等从而抽象出“业务模型”。测试环境与数据准备性能测试环境应尽可能模拟生产环境的架构服务器配置、中间件版本、网络拓扑等。数据方面需要准备足够量级且符合业务特征的测试数据例如百万级的用户账号、商品信息等避免因数据量不足导致缓存命中率虚高影响测试结果真实性。脚本开发与增强利用LoadRunner VuGen录制或编写脚本。这一步不仅仅是“录下来能回放”更重要的是让脚本变得“智能”和“健壮”。这包括事务划分用lr_start_transaction和lr_end_transaction将关键业务步骤如“用户登录”、“添加商品到购物车”包裹起来以便后续单独分析其性能。参数化将脚本中的固定数据如用户名、密码、商品ID替换为从文件或数据库中读取的参数模拟不同用户的行为避免因数据重复导致缓存或数据库锁竞争失实。关联处理服务器返回的动态值如Session ID、Token、订单号通过web_reg_save_param等函数捕获并回传给后续请求这是脚本能否成功回放的关键。添加集合点在需要模拟瞬时并发如秒杀场景的操作前插入lr_rendezvous函数让虚拟用户在此等待达到指定数量后同时释放制造峰值压力。设置思考时间与步调通过lr_think_time模拟用户操作间隔通过迭代间隔Pacing控制业务节奏使压力曲线更贴合真实场景。场景设计与执行在LoadRunner Controller中将脚本、虚拟用户数量、负载生成器Load Generator、调度策略如用户渐增、持续加压、波浪式压力组合成一个测试场景。这是将“脚本”转化为“压力”的指挥中心。系统监控在执行场景的同时需要监控被测系统的各项资源指标如服务器的CPU使用率、内存占用、磁盘I/O、网络流量以及数据库的连接数、慢查询、缓存命中率等。LoadRunner可以集成监控如Windows的PerfmonLinux的nmon/rstat但通常需要测试人员提前配置好。结果分析与报告测试结束后使用LoadRunner Analysis分析结果。这不仅仅是看“平均响应时间”更要分析事务响应时间随时间的变化曲线、TPS每秒事务数与并发用户数的关系、错误率、系统资源瓶颈点等并形成性能测试报告给出明确的结论和建议。2.2 LoadRunner在流程中的核心价值理解了流程我们再回头看LoadRunner。它的强大之处在于提供了一个集成的平台覆盖了从脚本开发VuGen、场景控制Controller到结果分析Analysis的全链路。特别是Controller它允许你以图形化的方式精细地控制压力的形态这是很多开源工具需要复杂脚本才能实现的功能。它的价值在于让测试工程师能够更专注于测试策略和结果分析而不是纠缠于压力如何发起的底层实现。注意很多新手会陷入“工具万能论”的误区认为用了LoadRunner就自动完成了性能测试。实际上工具输出的是一堆原始数据而如何设计场景、如何解读数据背后的系统行为才是测试工程师的核心竞争力。没有清晰的测试目标和模型再强大的工具也只会产生一堆无意义的数字。3. LoadRunner Controller场景设计的艺术与科学当我们拥有了一个或多个健壮的VuGen脚本后真正的性能测试舞台——Controller——才拉开帷幕。这里不是简单地设置“100个用户跑10分钟”每一个配置项背后都对应着对业务场景的一种假设。3.1 构建一个基础场景启动Controller选择“新建场景”通常我们会选择“手动场景”以获得最大的控制灵活性。接下来我们需要完成几个核心配置添加脚本与负载生成器将VuGen脚本添加到场景中。如果测试压力较大单台负载机本机可能无法模拟足够多的虚拟用户或者自身会成为瓶颈。这时需要配置“负载生成器”Load Generator将压力分发到多台机器上。在“场景”菜单的“负载生成器”中可以添加其他机器的IP并确保Controller主机与负载生成器主机之间的网络连通且防火墙放行了相关端口默认2058、54345等。设计用户组与计划这是场景设计的核心。在“设计”视图中你可以为每个脚本分配虚拟用户数。关键不在于总数而在于“用户如何被调度”。初始化虚拟用户以何种方式启动是同时初始化所有用户可能对负载机造成瞬间压力还是每隔一段时间初始化一定数量的用户启动用户初始化后何时开始运行脚本可以立即启动也可以延迟启动。持续时间用户运行脚本多久可以运行固定时长也可以运行完一定迭代次数后停止。停止用户是同时停止还是逐渐停止3.2 理解并设置关键调度策略加压模型LoadRunner的调度器Scheduler提供了几种经典的加压模型对应不同的测试目的经典模式默认直接设置并发用户数、运行时间和停止方式。比较直接但不够灵活。面向目标模式设定一个测试目标如事务响应时间低于3秒让LoadRunner自动调整用户数来达到或逼近该目标。常用于探索性测试寻找系统的性能拐点。自定义调度推荐手动定义加压阶段这是最贴近真实场景的方式。一个典型的压力曲线包括Ramp Up爬升期虚拟用户数从0逐渐增加到目标值。例如在10分钟内增加到500个用户。这模拟了系统在早高峰或活动开始时的压力增长过程。爬升速率不宜过快否则大量用户可能卡在初始化或登录阶段导致压力并未真正施加到业务上反而让负载机资源紧张。Duration稳定期虚拟用户数保持在目标值如500个运行一段时间如30分钟。这是评估系统在稳定压力下性能表现的关键阶段看各项指标是否平稳。Ramp Down退出期虚拟用户数从目标值逐渐减少到0。这模拟了用户逐渐离开的过程也给系统一个平缓的释放过程便于观察资源回收情况。实操心得设置爬升期时我通常会遵循“先慢后快”的原则。例如前1/3的时间加载较慢的用户数确保系统基础服务如数据库连接池、应用服务器线程池有充足时间预热和扩容后2/3时间可以加快加载速度。同时一定要在场景运行期间通过Controller的“运行”视图实时观察“运行Vuser”图确保用户是按预期状态如“运行中”、“已完成初始化”增长的而不是大量处于“挂起”或“错误”状态。3.3 配置运行时设置Run-Time Settings在场景中你可以批量修改所有虚拟用户的运行时设置这比在VuGen中逐个修改脚本高效得多。关键设置包括思考时间Think Time这里可以统一忽略思考时间、按录制比例回放思考时间或使用固定值。在容量测试或压力测试中通常会忽略思考时间或将其设置为一个很小的值目的是在单位时间内产生最大的请求压力探知系统极限。而在模拟真实场景的负载测试中则需要按比例回放。迭代次数与步调Pacing控制一个用户运行完一次脚本迭代后隔多久开始下一次迭代。设置较短的步调间隔可以加大请求密度。日志在调试阶段可以开启“始终发送消息”级别的日志但在正式压测时为了减少I/O开销对负载机性能的影响务必选择“仅在出错时发送消息”或“禁用日志”。速度模拟Speed Simulation可以模拟不同的网络带宽如拨号、宽带这对于测试网络敏感型应用很有用。错误处理可以设置当发生错误时是继续执行脚本、停止当前迭代还是停止整个Vuser。通常选择“继续”以避免个别错误导致整个虚拟用户退出影响整体并发数。4. 系统资源监控找到瓶颈的眼睛只压测不监控就像只开车不看仪表盘。LoadRunner Controller提供了良好的集成监控能力可以实时收集被测服务器的性能计数器数据。4.1 配置Windows资源监控对于Windows服务器通常使用“Windows资源”监控器。在Controller的“运行”视图中点击“监控器”区域的“添加度量”。输入被测服务器的IP地址。选择要监控的指标。对于常规的Web应用服务器我必看的计数器包括Processor(_Total)% Processor TimeCPU总使用率。持续高于80%可能成为瓶颈。Memory\Available MBytes可用物理内存。如果持续减少并接近零可能导致大量页面交换性能急剧下降。PhysicalDisk(_Total)% Disk Time和Avg. Disk Queue Length磁盘繁忙程度和队列长度。如果磁盘时间持续很高且队列长度大于2说明磁盘I/O可能存在瓶颈。Network Interface(*)\Bytes Total/sec网络接口总流量用于判断网络带宽是否吃紧。需要确保Controller主机有权限访问远程服务器的性能计数器。通常需要在被测服务器上通过“组策略编辑器”或命令行winmgmt /standalonehost等操作设置WMIWindows Management Instrumentation的访问权限并关闭防火墙或开放相应端口如135。4.2 配置Linux/Unix资源监控对于Linux服务器LoadRunner通常通过rstatd或ssh协议进行监控。更常见且强大的做法是使用独立的监控工具如nmon然后在Analysis中导入数据。不过Controller也支持添加“Unix资源”监控。在被测Linux服务器上安装并启动rstatd服务具体安装命令因发行版而异如yum install rstatd。在Controller中添加“Unix资源”监控输入服务器IP。关键监控指标包括Average load系统平均负载1分钟、5分钟、15分钟。如果1分钟负载值持续高于CPU核心数说明系统过载。Collision rate网络冲突率过高可能指示网络问题。CPU utilizationCPU使用率。Disk traffic磁盘读写流量。Paging rate页面交换率过高说明物理内存不足。避坑技巧监控本身也会消耗少量系统资源。对于高并发的压测建议将被监控的计数器数量控制在必要范围内并适当增加监控数据采样间隔如默认5秒改为10秒以减少对被测系统的干扰。更专业的做法是使用APM应用性能监控工具如Pinpoint、SkyWalking等它们能从应用内部提供代码级、链路级的性能洞察与LoadRunner的外部压力数据结合分析定位瓶颈事半功倍。5. 执行测试与实时诊断配置好场景和监控后就可以点击“开始场景”按钮了。但执行并非“启动后等待结束”而是需要实时观察随时准备干预。5.1 执行期间的观察要点在“运行”视图下重点关注以下几个实时图表运行Vuser查看虚拟用户的状态分布。理想情况下“运行中”的用户数应平稳达到预设值。如果大量用户卡在“初始化”、“挂起”或“错误”状态需要立即暂停检查。可能的原因有负载机资源不足、脚本初始化失败如登录关联失败、被测系统连接数已满等。每秒事务数TPS这是衡量系统处理能力的黄金指标。观察TPS曲线是否随着用户数的增加而相应增长并在稳定期保持平稳。如果用户数增加而TPS不增反降或剧烈波动说明系统已经出现瓶颈。事务响应时间观察关键事务如登录、下单的平均响应时间曲线。响应时间应保持在可接受范围内并相对稳定。如果响应时间随压力增加而线性甚至指数增长是典型的性能瓶颈信号。错误数/秒监控错误率。偶尔的错误可能正常但如果错误数持续飙升必须立即停止测试检查错误原因是脚本问题、参数化数据耗尽还是服务器返回了5xx错误。系统资源监控图将上述事务指标与CPU、内存、磁盘I/O等资源图关联起来看。例如当TPS达到峰值时CPU使用率也接近100%那么CPU很可能就是当前的瓶颈。5.2 常见执行问题与现场排查问题虚拟用户大量失败错误信息为“Action.c(x): Error -27796: Failed to connect to server”排查首先检查网络连通性ping, telnet端口。更常见的原因是被测服务器的连接池如Web容器的最大线程数、数据库的最大连接数被耗尽。需要检查服务器日志并适当调大相关配置。问题TPS曲线出现规律的“锯齿状”波动排查这通常与垃圾回收GC有关。观察服务器的内存使用率和GC日志。如果每次TPS下跌都伴随着一次Full GC说明存在内存泄漏或堆内存设置不合理。问题平均响应时间尚可但90%或95%分位响应时间非常高排查这说明系统处理能力不均衡部分请求遇到了严重阻塞。可能的原因有数据库中存在慢查询、某些外部接口调用超时、应用内部有锁竞争如同步锁、数据库行锁。需要结合应用日志和数据库慢查询日志进一步分析。6. LoadRunner Analysis从数据海洋到性能洞见测试执行完毕我们得到了一个结果目录.lrr文件。用Analysis打开它才是性能测试“收获”的开始。Analysis提供了海量的图表新手很容易迷失。我的分析习惯是遵循一个清晰的路径。6.1 分析三部曲概要、钻取、关联第一步阅读“分析摘要”打开结果后首先看“分析摘要”。这里提供了整个测试的概览虚拟用户数、总吞吐量、总点击数、平均/最大响应时间、通过/失败的事务数等。它能给你一个整体印象测试是否成功执行整体性能是否达标第二步核心事务分析这是分析的重点。在“事务摘要”图中找到你定义的关键事务如“Login”、“AddToCart”。平均响应时间是否符合性能需求最小/最大响应时间差异是否巨大最大时间是否异常通过率是否100%如果不是失败的事务集中在哪个时间段深入钻取右键点击某个事务选择“事务性能摘要图”。这里可以看到该事务在整个测试期间的响应时间曲线。将其与“运行Vuser”图叠加在图上右键-合并图表可以直观看出响应时间随并发用户数变化的趋势。是线性增长还是到某个点后急剧上升那个点可能就是性能拐点。第三步系统资源关联分析性能问题的根源最终会体现在资源消耗上。将事务响应时间图与之前添加的Windows/Unix资源监控图进行关联分析。在Analysis中可以将多个图表合并到一个视图中。例如将“事务响应时间Login”图与“Windows资源 - %Processor Time”图合并。观察相关性当Login事务响应时间开始飙升时CPU使用率是否也同步达到饱和如果是则CPU是瓶颈。如果CPU不高但磁盘队列长度很高则可能是磁盘I/O瓶颈。如果网络流量饱和则可能是带宽瓶颈。6.2 生成专业报告Analysis支持生成HTML或Word格式的报告。但自动生成的报告往往过于冗长。我通常的做法是在Analysis中通过“设置筛选条件”和“设置图表属性”将最关键的几个图表如运行Vuser图、TPS图、关键事务响应时间图、核心资源CPU/内存图调整到最清晰的状态。使用“报告”-“新建报告”功能创建一个自定义报告模板只包含这些核心图表和摘要数据。将图表以图片形式导出连同自己的分析结论如在500并发下系统TPS达到150登录事务平均响应时间1.2秒满足需求当并发增至800时CPU使用率持续超过90%成为系统瓶颈建议扩容或优化XX服务代码整理成一份简洁明了的性能测试报告。终极心得LoadRunner Analysis给出的数据是“现象”测试工程师的价值在于解读“现象”背后的“原因”。不要只报告“系统在500用户下变慢了”而要尝试回答“为什么在500用户时会变慢是哪个组件、哪段代码、哪种资源最先达到极限” 这需要你不仅会看LoadRunner的图还要懂一些操作系统、网络、中间件和数据库的知识并能与开发、运维团队一起基于数据证据进行推理和验证。性能测试归根结底是一场寻找系统短板并推动优化的侦探游戏。