共计 2442 个字符，预计需要花费 7 分钟才能阅读完成。

为什么需要系统学习性能测试工具？

去年我们的电商系统在大促时遭遇了严重的性能问题：

• 订单提交接口在 300 并发时响应时间从 1 秒飙升到 15 秒
• 支付成功率因超时从 99% 跌至 72%
• 事后分析发现测试时使用的固定测试数据导致缓存命中率虚高

这些问题暴露出我们在性能测试工具使用上的三个薄弱环节：

1. 没有正确设置思考时间(Think Time)，导致测试压力远高于实际场景
2. 参数化数据量不足，未能真实模拟用户行为多样性
3. 漏掉了关键业务的集合点 (Rendezvous Point) 设置

工具选型：LoadRunner vs PerformanceRunner

在开始实战前，先明确工具选择。两款主流工具的核心差异如下：

对于需要测试复杂企业级应用的情况，LoadRunner 仍是首选。下面以 LoadRunner 2020 为例演示完整流程。

一、脚本录制与调试

1.1 录制 WebTours 示例脚本

1. 启动 Virtual User Generator(VuGen)
2. 选择 Web - HTTP/HTML 协议
3. 点击录制按钮，浏览器自动打开 WebTours
4. 完成登录→查询航班→订票→退出的完整流程
5. 停止录制后自动生成基础脚本

关键配置项：

// LoadRunner VuGen 脚本示例
Action()
{
    // 设置思考时间模式为随机百分比
    lr_set_think_time_mode(LR_THINK_TIME_RANDOM_PERCENTAGE, "min=70% max=130%");

    web_url("WebTours", 
        "URL=http://localhost:1080/WebTours/", 
        "Resource=0", 
        "RecContentType=text/html", 
        LAST);

    // 登录操作
    web_submit_form("login.pl",
        ITEMDATA,
        "Name=username", "Value={username}", ENDITEM,
        "Name=password", "Value={password}", ENDITEM,
        LAST);

    return 0;
}

1.2 参数化实现

1. 右键点击脚本中的固定值选择Parameterize
2. 创建 CSV 参数文件user_credentials.dat：

   username,password
   jojo,bean
   lisa,simpson
   mike,password123

3. 设置参数属性：
4. Select column: By name
5. Update value: Each iteration
6. When out of values: Abort Vuser

1.3 事务与集合点

// 在订票操作前后添加事务
lr_start_transaction("book_flight");

web_submit_form("reservations.pl", 
    ITEMDATA, 
    "Name=depart", "Value=Denver", ENDITEM,
    "Name=arrive", "Value=London", ENDITEM,
    LAST);

lr_end_transaction("book_flight", LR_AUTO);

// 在支付前设置集合点
lr_rendezvous("before_payment");

二、场景设计实战

2.1 梯度加压配置

在 Controller 中设置阶梯式负载：

1. 初始 5 个虚拟用户(Virtual User)
2. 每 2 分钟增加 10 个用户
3. 达到 50 用户后持续运行 15 分钟
4. 最后 5 分钟逐步释放用户

对应的负载模式配置图：

[用户数]
   |
50|               ________
   |              /        \
   |             /          \
   |____/       /            \
 0 +---+-------+--------------+---> [时间]
   0   2min    17min         22min

2.2 负载机配置策略

• 主控机只运行 Controller
• 每台负载机建议运行：
• ≤500 Vusers (Windows 负载机)
• ≤1000 Vusers (Linux 负载机)
• 确保负载机间时钟同步(NTP)

三、结果分析要点

3.1 关键指标关联分析

• 当 TPS(Transactions Per Second)达到峰值时：
• 响应时间是否突增？
• 错误率是否上升？
• 典型问题模式：
• TPS 平坦但响应时间持续上升 → 系统资源瓶颈
• TPS 波动剧烈 → 后端服务不稳定

3.2 常见瓶颈定位

1. CPU 瓶颈：
2. Windows: Perfmon 中% Processor Time >80%
3. Linux: top显示 us+sy >70%
4. 内存瓶颈：
5. Available MBytes <10% 总内存
6. 磁盘 I /O：
7. Avg. Disk sec/Transfer >0.02s

四、避坑指南

4.1 关联处理

回放失败时检查：

// 自动关联函数示例
web_reg_save_param_ex(
    "ParamName=sessionID",
    "LB=name=userSession value=",
    "RB=>",
    SEARCH_FILTERS,
    LAST);

4.2 虚拟用户数估算

计算公式：

Vusers = (峰值小时请求量 × 平均响应时间) / 3600

示例：
– 预期峰值 10 万请求 / 小时
– 平均响应时间 800ms
– 所需 Vusers = (100000×0.8)/3600 ≈ 22

4.3 Linux 监控配置

1. 安装 rstatd 服务
2. Controller 添加 Linux 资源计数器时：
3. 使用 root 账号
4. 检查防火墙端口(udp 111)

进阶思考

1. 如何设计包含登录、浏览、下单、支付的混合场景比例？
2. 当测试结果出现较大波动时，应该检查哪些系统级指标？
3. 如何验证数据库连接池配置是否合理？

通过这个完整流程的实践，你应该已经掌握了性能测试的核心技能链。记住，好的性能测试不在于工具使用多熟练，而在于能否设计出反映真实业务场景的测试方案。