LoadRunner 的核心思想是：通过模拟成千上万的虚拟用户（Vuser）来对服务器施加压力，从而测量服务器在不同负载下的性能表现，并找出瓶颈。
（图片来源网络，侵删）
整个过程可以分为三个主要阶段：计划设计、脚本执行、结果分析。
第一阶段：计划与设计
在开始录制脚本之前,周密的计划是成功的关键。
明确测试目标
- 基准测试: 在当前负载下，系统表现如何？建立性能基准线。
- 容量规划: 系统能承受多少用户？最大TPS是多少？在什么情况下系统会崩溃？
- 瓶颈定位: 系统的瓶颈在哪里？是CPU、内存、网络,还是应用程序本身？
- 调优验证: 对系统进行优化（如修改JVM参数、优化SQL、增加硬件）后,性能是否有提升？
- 稳定性测试: 在一个较长的时间内，让系统承受一定的负载，观察是否存在内存泄漏、性能下降等问题。
定义性能指标
你需要明确要关注哪些数据,这些数据通常来自不同的监控点：
| 指标类别 | 关键指标 | 说明 | 监控工具 |
|---|---|---|---|
| LoadRunner自身指标 | 并发用户数 | 同时在线操作的用户数。 | LoadRunner Controller |
| TPS/Throughput (吞吐量) | 系统每秒处理的事务数，这是衡量系统处理能力的核心指标。 | LoadRunner Analysis | |
| 平均事务响应时间 | 一个事务从发起到完成所花费的平均时间，用户最直观的感受。 | LoadRunner Analysis | |
| 错误率 | 执行失败的事务占总事务的百分比。 | LoadRunner Analysis | |
| 服务器硬件指标 | CPU使用率 | 核心指标，持续高于70%-80%通常是瓶颈。 | 服务器任务管理器、nmon、top、vmstat |
| 内存使用率 | 应用堆内存、非堆内存使用情况，关注是否存在内存泄漏。 | 服务器任务管理器、nmon、top、free | |
| 磁盘I/O | 磁盘读写速率、IOPS（每秒读写次数），高I/O等待时间是瓶颈。 | iostat、nmon、sar | |
| 网络I/O | 网络带宽使用率、网络延迟。 | iftop, netstat, nload |
|
| 应用与中间件指标 | JVM/GC情况 | 垃圾回收频率和耗时，堆内存使用情况，频繁Full GC是严重瓶颈。 | JConsole, VisualVM, jstat |
| 数据库指标 | SQL查询时间、锁等待、连接池使用率、缓存命中率。 | 数据库慢查询日志、show processlist、top |
|
| Web服务器指标 | Apache/Nginx的并发连接数、请求处理队列长度。 | top, ps, 服务器自带监控模块 |
设计场景
在 LoadRunner Controller 中,你需要设计一个测试场景来模拟真实用户行为。
（图片来源网络，侵删）
- 用户类型： 模拟哪些类型的用户？（普通浏览用户、下单用户、管理员）
- 负载模式：
- Ramp-Up (渐增): 在设定的时间内，逐步增加Vuser数量，模拟真实用户涌入,这是最常用的方式。
- Steady State (稳定): 立即启动所有Vuser,并保持数量不变。
- Ramp-Down (渐减): 逐步减少Vuser数量。
- 思考时间: 模拟用户在操作之间的停顿时间,这对模拟真实负载至关重要。
- 运行持续时间: 测试需要持续多长时间。
第二阶段：脚本执行与监控
这是执行测试并收集数据的阶段。
录制与优化脚本
- 使用 VuGen 录制用户的核心业务流程（如登录、浏览商品、加入购物车、下单）。
- 参数化： 将用户名、密码、商品ID等动态数据用参数（如
lr_eval_string）替换,以便模拟多用户。 - 关联： 将服务器返回的动态值（如 Session ID, Token）提取出来，供后续请求使用,这是脚本能否成功运行的关键。
- 添加事务： 将有意义的业务操作（如下单）标记为“事务”,以便在结果中分析其响应时间。
执行测试与实时监控
在 Controller 中启动场景，并打开 “Run” 视图，这是性能测试的“驾驶舱”。
-
上半部分 - Vuser图：
- Vuser Running (运行中): 正在执行脚本的Vuser数量。
- Vuser Passed (通过): 成功完成脚本的Vuser。
- Vuser Failed (失败): 执行失败的Vuser。
- Vuser Elapsed Time (已用时间): Vuser运行的总时间。
- 目标： 观察运行中的Vuser是否按预期增加,失败的Vuser是否突然增多。
-
下半部分 - 系统资源图：
（图片来源网络，侵删）- LoadRunner Resources: LoadGenerator（负载机）自身的CPU、内存使用情况,确保负载机不是瓶颈。
- Web/FTP/Database Servers: 你需要在这里添加被测服务器的监控指标。
- 如何添加： 在下方服务器列表中，点击 "Add Measurements" -> "Add MS Windows Resources" 或 "Add UNIX Resources",输入服务器IP和凭证。
- 目标： 实时观察服务器资源的变化趋势。 这是定位瓶颈最直接的方式。
执行过程中的关键观察点：
- 初始阶段： 随着Vuser增加，TPS上升，响应时间平稳，CPU等资源使用率缓慢上升,一切正常。
- 压力阶段： Vuser继续增加，TPS增长变缓，响应时间开始明显增加，某个或某几个资源（如CPU）使用率达到一个高位（如70%以上）。
- 拐点/瓶颈阶段： TPS达到峰值后开始下降，响应时间急剧上升，错误率开始飙升，这通常意味着系统已经达到其处理能力的极限,出现了瓶颈。
- 恢复阶段： Vuser开始减少，TPS和响应时间是否会恢复正常？还是持续在高水平？这有助于判断系统是否存在稳定性问题（如内存泄漏）。
第三阶段：结果分析与瓶颈定位
测试结束后，使用 LoadRunner Analysis 工具对收集到的海量数据进行深入分析。
总体概览
- Summary Report: 查看关键指标的汇总，如总事务数、平均/最小/最大响应时间、每秒事务数、错误率等,快速了解测试的整体情况。
核心图表分析
这是分析的重点,通过图表的关联来定位瓶颈。
-
TPS vs. Vusers 图:
- 分析： 这是寻找系统拐点和最大处理能力的最重要图表，观察TPS曲线的顶点,对应的Vuser数量和TPS值就是系统的最大容量。
-
Average Transaction Response Time vs. Vusers 图:
- 分析： 当响应时间曲线开始急剧上升时，通常与TPS曲线的拐点相对应,这标志着用户体验开始急剧下降。
-
资源使用率 vs. Vusers 图:
- 分析： 将TPS、响应时间图与CPU、内存、磁盘、网络图放在一起对比。
- 瓶颈定位的核心逻辑：
- 如果CPU率先达到100%： 很可能是CPU瓶颈，原因可能是：CPU密集型算法、频繁的SQL计算、线程过多导致上下文切换开销大。
- 如果内存持续增长且不回收： 很可能是内存泄漏,需要结合JVM或应用的内存分析工具。
- 如果磁盘I/O等待时间很高： 很可能是磁盘瓶颈，原因可能是：频繁的日志写入、大量的数据库磁盘I/O、文件读写操作多。
- 如果网络带宽使用率达到90%以上： 很可能是网络瓶颈，原因可能是：返回数据量过大（如大图片、JSON）、网络架构设计问题。
深入分析
- 事务分析： 在 "Transactions" 视图中，查看每个事务的详细表现，哪个事务响应时间最长？错误率最高？这能帮你定位到具体的问题业务模块。
- Web页面细分： 分析一个网页中每个元素（HTML, JS, CSS, 图片）的下载时间,找出是哪个资源拖慢了页面加载速度。
- 错误分析： 查看所有失败的请求，分析错误原因（如超时、连接被拒绝、HTTP 5xx错误）,这直接指向了应用程序或服务器的具体问题。
一个典型的瓶颈定位场景示例
- 现象： 在测试中，Vuser数增加到500时，TPS达到峰值1000 tps；当Vuser增加到600时，TPS下降到800 tps，同时下单事务的平均响应时间从2秒飙升到15秒，错误率上升到10%。
- 分析：
- 打开Analysis，将 TPS vs. Vusers 图和 Average Transaction Response Time vs. Vusers 图叠加，确认在500 Vuser处出现了拐点。
- 打开 资源使用率 图，发现此时服务器的 CPU使用率 稳定在98%。
- 系统的瓶颈在 CPU，当并发请求超过500时，CPU资源耗尽，无法处理更多的请求，导致TPS下降,响应时间变长。
- 后续行动：
- 与开发人员沟通，检查下单相关的代码逻辑,看是否存在可以优化的循环或计算。
- 检查数据库慢查询日志,看是否有复杂的SQL查询消耗了大量CPU。
- 考虑增加服务器CPU核心数或进行水平扩展。
使用 LoadRunner 进行服务器性能测试是一个系统性的工程，其核心在于 “数据驱动” 和 “关联分析”。
- 数据驱动： 一切结论都来自于 Controller 和 Analysis 中的客观数据,而不是主观猜测。
- 关联分析： 不要孤立地看任何一个指标，必须将 用户行为、应用性能 和 服务器资源 三方面的数据放在一起进行关联分析,才能准确地定位瓶颈。
通过以上流程，你可以有效地利用 LoadRunner 评估服务器性能,为系统的优化和扩容提供强有力的数据支持。
