尧图网站建设 
简介「LoadRunner性能测试报告.doc」是面向软件测试学习者与性能测试入门者的实战报告文档围绕 HP Web Tours 在线订票系统展开完整性能测试实践。内容涵盖系统三层架构与功能模块说明、登录—浏览—加购—结算—支付的业务流程梳理、登录验证与数据库查询及支付处理等关键测试点以及测试环境配置并给出吞吐量、响应时间、并发用户负载、CPU 与内存资源利用率等指标的测试方法与期望值通过 Vuser 脚本模拟不同负载级别记录运行状况与测试场景数据最终输出结果分析与数据库查询优化、代码结构调整等改进建议。资源包共 1 个 doc 文件约 677KB结构与目录清晰可直接作为课程实训报告模板或性能测试流程参考。目前已有 1304 人学习下载适合需要熟悉 LoadRunner 测试流程、报告撰写与性能瓶颈分析思路的读者。1. 从一份性能测试报告反向校验 LoadRunner 的压测设计一份性能测试报告里最容易骗人的地方往往不是那些炫目的图表而是“跑了两轮就好了”这类叙述。HP Web Tours 订票系统的被测对象核心只有注册、登录、查询航班三个动作但当 200 个并发用户同时压上来AP 服务器 CPU 直接顶到 100%数据库侧 IO 等待居高不下Audit_Transaction 响应时间飙到 190 秒——问题不一定出在业务逻辑很可能出在脚本流程和场景设计上尤其是“登录”这件事有没有按真实用户习惯处理。这份报告两次执行的差异只有一处第一次每笔交易都重新登录第二次每个 Vuser 只登录一次、后续交易复用会话。结果第一次跑到 30 分钟就因登录超时连锁失败被迫中止第二次稳定跑满 50 分钟。这说明 LoadRunner 这类工具只是放大器脚本结构决定了你测的是系统能力还是自己制造出来的排队。下面按脚本录制、事务划分、场景设计、指标采集、慢事务定位的顺序拆开适合正在写性能测试报告或者刚跑完 LoadRunner 但对着数据没底的人。2. Vuser 脚本录制与事务划分登录、查询航班怎么拆才合理LoadRunner 的脚本是后续所有场景和报告的地基。脚本录得粗事务边界划得乱后面加再漂亮的图表也是错的。HP Web Tours 的三个核心交易——注册、登录、查询航班——每个的录制方式和事务切法都不一样需要单独处理。2.1 协议选型与 HTTP/HTML 录制模式HP Web Tours 是典型 B/S 系统客户端通过浏览器访问选Web (HTTP/HTML)协议即可。VuGen 新建脚本时勾选该协议录制级别建议用基于 HTML 的脚本而不是 URL 模式。原因是 HTML 模式下 LoadRunner 会把一个页面里所有资源请求自动合成一条web_url或web_submit_data脚本可读性和可维护性都更好URL 模式会把每个 gif、js 都录成独立请求后期回放容易因静态资源变动而误报失败。录制时容易踩的两个坑一是浏览器代理设置冲突常见做法是先关掉本地浏览器代理录制完成后再恢复二是录制过程中 View State、Session ID 这类动态值会被硬编码进脚本直接回放必然失败必须在录制后用关联Correlation替换。2.2 事务边界登录、查询分别是一笔还是两笔事务Transaction的粒度直接决定报告里响应时间的含义。这份报告里登录和查询航班被拆成独立事务是合理的因为两者在业务上对应不同的用户动作在性能上瓶颈也往往落在不同层。脚本里用lr_start_transaction/lr_end_transaction包裹Action() { // 静态资源无需单独计事务 web_url(WebTours, URLhttp://192.168.1.100:1080/WebTours/, Resource0, RecContentTypetext/html, Snapshott1.inf, ModeHTTP, LAST); // 登录事务边界从提交登录表单到跳转首页 lr_start_transaction(login_transaction); web_submit_data(login.pl, Actionhttp://192.168.1.100:1080/WebTours/login.pl, MethodPOST, RecContentTypetext/html, Refererhttp://192.168.1.100:1080/WebTours/nav.pl?inhome, Snapshott2.inf, ModeHTTP, ITEMDATA, NameuserSession, Value{userSession}, ENDITEM, Nameusername, Value{username}, ENDITEM, Namepassword, Value{password}, ENDITEM, Namelogin.x, Value52, ENDITEM, Namelogin.y, Value10, ENDITEM, LAST); // 用检查点确认登录真的成功而不是拿到了错误页 web_reg_find(TextWelcome, SaveCountlogin_count, LAST); lr_end_transaction(login_transaction, LR_AUTO); return 0; }逻辑说明lr_start_transaction与lr_end_transaction之间是事务的计时区间只有这段区间内的服务器处理时间才会被计入响应时间。LR_AUTO表示由 LoadRunner 自动判定事务通过还是失败。检查点web_reg_find必须注册在请求之前否则无法拦截响应内容。参数说明Resource0表示这条请求不计入页面资源统计仅作为页面跳转Snapshot用于回放失败时定位问题可以保留ModeHTTP是录制时的默认模式与 HTML 单元回放兼容。提示事务名不要用中文LoadRunner Controller 和 Analysis 对中文事务名的排序和筛选支持不稳定用英文小写下划线是最省事的做法。2.3 关联与参数化userSession 和用户资料的处理userSession是 HP Web Tours 每次登录后下发的动态值硬编码回放必然失败必须做关联。常见做法是在录制时打开“自动关联”或者在脚本里手动加web_reg_save_paramweb_reg_save_param(userSession, LBname\userSession\ value\, RB\, SearchBody, LAST);LB和RB是左右边界SearchBody指定只在响应正文里找。这个函数也必须放在产生该值的请求之前。用户数据则用参数化而不是每个 Vuser 硬编码一份账号密码。在 Parameter List 里建一个username参数表用UniqueOnce的组合每个 Vuser 取一行登录时用它填表单。这样 200 个并发用户就能模拟 200 个不同身份避免服务端会话互踢。2.4 回放验证与迭代次数确认脚本写完先单用户回放日志等级调到 Extended逐条核对每个请求的返回码和检查点。确认无误后把Run-time Settings里的 Run Logic 迭代次数设为 1先跑通。注册和查询航班两段脚本在报告里对应不同的事务名回放时应该分别看到login_transaction、register_transaction、query_transaction三条事务记录任何一条缺失或超时都要回脚本里找原因不要直接进 Controller 压测。3. 场景设计逐步加压、瞬间加压与 3 台 PC 的分工脚本能在单机回放通过只代表语法对了。真正决定报告可信度的是 Controller 里的场景配置。这份报告做了 200、400、700、1000 四个用户档位但真正跑出结果的是 200 并发那一档其配置思路值得展开。3.1 手动场景还是目标场景Controller 提供两种场景模型手动场景Manual Scenario和目标场景Goal-Oriented Scenario。目标场景是设定一个目标如 TPS 达到 100 或响应时间稳定在 5 秒内由工具自动调节并发用户数去逼近适合验收类测试手动场景是用户数、加压节奏、持续时间全部手工指定适合找瓶颈。这份报告用的是手动场景因为目的是“看系统在多大的压力下崩”而不是“验证系统能不能扛住 500 TPS”。两种场景在分析阶段的意义不同手动场景跑出来的吞吐曲线能让你看到拐点目标场景只能告诉你目标达成没达成。3.2 加压节奏逐步加压和瞬间加压怎么选报告里提到两种加压方式每隔 2 秒启动 1 个 Vuser以及一次性启动 10 个或 100 个。这两种方式在 Controller 里分别对应 Ramp-up 配置加压方式Controller 配置适用场景观察重点逐步加压Ramp-up 每 2 秒启动 1 Vuser找系统稳定吞吐上限TPS 拐点和响应时间跃变瞬时加压Ramp-up 设为 0同时启动模拟突发流量、开机洪峰短时错误率和恢复速度阶梯加压分批设置每批 50 用户定位在哪个并发量开始劣化各档位资源利用率对比逐步加压能明确看到“在多少用户数之后响应时间开始指数上升”这个拐点比最大 TPS 更有价值。瞬间加压则更考验连接池、线程池、数据库连接数的初值设置是否合理短时间内的错误率会显著高于逐步加压。3.3 分布式负载生成器的部署与分配报告里用了 3 台 PC 承载 200 个并发用户两台各 70 左右一台 60 左右并同时跑 Controller。这种部署在中小规模压测里非常常见但有两条硬约束要注意每台负载机Load Generator能承载的 Vuser 数受 CPU、内存和网络带宽限制。跑 Web (HTTP/HTML) 协议时单台 4 核 8G 的机器大概能稳定跑 80~120 个 Vuser具体要看每个 Vuser 的脚本复杂度。Controller 所在机器同时跑 Vuser 会拉高自身 CPU影响加压精度能分开就分开。负载机在 Controller 里通过Load Generators面板添加IP 填内网地址连接方式选默认的Agent或Remote Management每台机器要预装 LoadRunner Agent 并启动服务Windows 上防火墙需放行对应端口。配置完成后点Connect状态全绿才算就绪。3.4 场景运行与实时监控的采集项Controller 的Run视图里需要打开几个关键图Running Vusers当前并发数、Transactions per SecondTPS、Average Transaction Response Time平均响应时间、Errors per Second错误数。AP 服务器和 DB 服务器的资源指标用 LoadRunner 自带的Web Resource Monitor或Windows Resource Monitor采集 CPU、Memory、Disk 计数器。这次报告里能拿出User% / Sys% / Wait%的三段数据就是因为提前在 Controller 里配好了 Windows 资源监控指向了两台主机的性能计数器。没配这一层后面分析就只能看业务层找不出到底是 CPU 满还是 IO 排队。3.5 场景持续时间与失败退出策略200 并发逐步加压大约 7 分钟到满报告里第一次跑了 30 分钟就崩是因为没有配事务失败比例触发停止。常见做法是在 Controller 的Scenario Schedule里加一个Stop scenario if transaction failure percentage exceeds X%比如设成 20%一旦登录事务大面积超时就能自动停在可分析的节点而不是等它跑成一锅粥。第二次稳定跑到 50 分钟是因为登录操作被提前收口后面所有交易共用同一会话脚本负载特征发生了根本变化。4. 指标采集与瓶颈定位从 AP 的 CPU 100% 拆到 DB 的 IO 等待报告出来之后最有价值的工作是回答三个问题哪个事务慢、慢在哪一层、下一轮该改什么。把两次测试的数据摊开对照答案就很清楚了。4.1 业务级指标响应时间、TPS、成功率业务层指标从 Analysis 里直接取三个口径必须说清楚平均响应时间所有成功事务的平均值容易被大量快事务拉低配合 90% 分位或最大值一起看。TPS单位时间内完成的事务数注意区分“成功 TPS”和“发起 TPS”报告里写的吞吐率应是成功交易量除以统计时段。成功率成功事务数除以发起事务数报告里给的期望值是大于 95%这个门槛对订票类业务是合理的。第一次测试里 AutoUW_Transaction 平均响应 3.73 秒、最大 387.87 秒这个最大值意味着链路里存在长时间的阻塞不是简单的高负载排队。第二次测试里 GeneralQuery_Transaction 平均 11 秒、最大 35 秒属于可接受的劣化。这种差异化才是分析要抓的重点。4.2 系统级指标AP 与 DB 两端的 CPU 与 IO 对照报告里 AP 服务器两次都跑到 95% 以上DB 服务器第一次 CPU 很低、IO 等待反而高第二次 CPU 上到 75%。这个组合说明第一次 AP 满、DB 闲说明瓶颈在应用层登录操作过于频繁导致 AP 端的会话处理、加密校验吃掉了 CPU业务请求根本到不了数据库。第二次 AP 依然满、DB CPU 上升、IO 等待依然高说明请求真正打到了数据库层数据库成了第二段瓶颈慢在物理 IO 上。把 AP 和 DB 两端数据放在一张表里对照比各画一张趋势图更能说服人阶段AP CPUDB CPUDB IO 等待明显慢的事务第一次1:52–2:20~100%20%较低登录相关全部超时第二次2:45–4:0095%75%较高Audit、ClaimRegister4.3 两次测试流程差异带来的数据解读两次测试唯一的变量是登录流程但因为登录是一个非常“重”的操作会话创建、密码校验、跳转它在 200 并发下的开销不可忽略。第一次每笔交易前都登录相当于把登录的负载乘以了交易次数AP 端 CPU 被反复叫醒做同一件事事务成功率自然崩塌。第二次改成每个 Vuser 只登录一次登录开销从“每交易一次”变成“每 Vuser 一次”AP 压力下降请求真正到达数据库于是 DB 端的 CPU 和 IO 都跟着上来了。从性能测试角度第二次的结果才是有效结果第一次只能作为“登录设计缺陷”的佐证。注意脚本流程变化后必须重新校准基线否则两次数据之间没有可比性。报告里把两次结果并列展示是对的但在结论里必须明确哪一次代表系统真实能力。4.4 慢事务定位Audit_Transaction 与 ClaimRegister_Transaction第二次测试里最扎眼的是两类交易Audit_Transaction 平均 162 秒、最大 207 秒ClaimRegister_Transaction 平均 143 秒、最大 163 秒。这两个事务的响应时间在整段测试中始终居高不下没有随登录完成而回落说明它们的慢与并发数无关是稳态慢事务。排查这类事务的常用套路在 Analysis 里打开Transaction Response Time (Percentile)图确认慢的是所有采样点还是尾部少数点。如果 90% 分位也远高于平均说明是脚本级的普遍慢如果只是平均值被拖高说明是长尾。打开Web Page Breakdown或Page Download Time Breakdown看时间花在 First Buffer、Receive 还是 Client Time。如果 Client Time 占比高问题可能在脚本本身的思考时间或参数化取数。在 AP 端开数据库慢查询日志把这两个事务对应的 SQL 抓出来常见原因是缺索引、全表扫描或锁等待。用Web Resource Monitor对比这两个事务执行时段的 DB 锁资源数量如果锁等待明显上升说明事务隔离级别或提交时机有问题。报告里提到这两个事务“超时严重、成功率很低”基本可以判断它们卡在数据库层。下一轮调优应该先做 SQL 审查和索引补齐而不是继续加机器。5. 从报告到落地登录复用、参数化与慢事务剥离的调优技巧性能测试最终要回答的是“下一步怎么改”。HP Web Tours 这套流程跑过两轮之后最值得复用的三个技巧是脚本层的登录复用、数据层的参数化隔离以及报告层的慢事务单独分析。下面按可复现的粒度展开。5.1 脚本层登录只跑一次交易循环复用会话登录复用是最直接有效的一招。实现方式是在脚本里用vuser_init段执行登录把userSession存到全局参数里Action段循环执行查询或业务交易不再重复登录vuser_init() { web_url(WebTours, ..., LAST); lr_start_transaction(login_transaction); web_submit_data(login.pl, ..., LAST); lr_end_transaction(login_transaction, LR_AUTO); // userSession 通过关联存到参数后续 Action 里复用 return 0; } Action() { // 复用初始化阶段拿到的 userSession只循环发查询交易 lr_start_transaction(query_transaction); web_submit_data(itinerary.pl, ..., LAST); lr_end_transaction(query_transaction, LR_AUTO); return 0; }这样每个 Vuser 只承担一次登录开销报告中业务层响应时间更能反映真实业务能力。vuser_init在整个场景中每个 Vuser 只执行一次Action才按迭代次数循环。5.2 数据层参数池按 Vuser 隔离避免账号互踢参数化时优先选Unique Once的组合每个 Vuser 从参数表里取一行独占使用避免多个 Vuser 抢同一个账号导致服务端会话互斥。如果业务账号不够可以退一步用 Unique Each iteration让每次迭代取不同的值但要确认服务端允许多会话并存。参数表里建议额外加一列状态备注压测完可以回溯哪个账号在哪个时段报错。5.3 报告层慢事务单独建图、单独下结论分析时把慢事务从总体平均线里剥离出来单独建图。Analysis 里右键Add New Graph→Transaction Response Time筛选出 Audit_Transaction、ClaimRegister_Transaction再和Running Vusers双 Y 轴叠加能直观看到它们的响应时间和并发数是否相关。如果两条曲线不平行说明慢是业务本身的问题如果平行上升说明是资源竞争。最终报告里“平均响应时间 15s、成功率 95%”这类期望值必须按事务分别列出实测值不能用一个总数概括全局否则慢事务永远会被快事务的平均值掩盖。本文还有配套的精品资源点击获取 LoadRunner 压测设计复盘：登录复用、场景加压与慢事务定位
简介「LoadRunner性能测试报告.doc」是面向软件测试学习者与性能测试入门者的实战报告文档围绕 HP Web Tours 在线订票系统展开完整性能测试实践。内容涵盖系统三层架构与功能模块说明、登录—浏览—加购—结算—支付的业务流程梳理、登录验证与数据库查询及支付处理等关键测试点以及测试环境配置并给出吞吐量、响应时间、并发用户负载、CPU 与内存资源利用率等指标的测试方法与期望值通过 Vuser 脚本模拟不同负载级别记录运行状况与测试场景数据最终输出结果分析与数据库查询优化、代码结构调整等改进建议。资源包共 1 个 doc 文件约 677KB结构与目录清晰可直接作为课程实训报告模板或性能测试流程参考。目前已有 1304 人学习下载适合需要熟悉 LoadRunner 测试流程、报告撰写与性能瓶颈分析思路的读者。1. 从一份性能测试报告反向校验 LoadRunner 的压测设计一份性能测试报告里最容易骗人的地方往往不是那些炫目的图表而是“跑了两轮就好了”这类叙述。HP Web Tours 订票系统的被测对象核心只有注册、登录、查询航班三个动作但当 200 个并发用户同时压上来AP 服务器 CPU 直接顶到 100%数据库侧 IO 等待居高不下Audit_Transaction 响应时间飙到 190 秒——问题不一定出在业务逻辑很可能出在脚本流程和场景设计上尤其是“登录”这件事有没有按真实用户习惯处理。这份报告两次执行的差异只有一处第一次每笔交易都重新登录第二次每个 Vuser 只登录一次、后续交易复用会话。结果第一次跑到 30 分钟就因登录超时连锁失败被迫中止第二次稳定跑满 50 分钟。这说明 LoadRunner 这类工具只是放大器脚本结构决定了你测的是系统能力还是自己制造出来的排队。下面按脚本录制、事务划分、场景设计、指标采集、慢事务定位的顺序拆开适合正在写性能测试报告或者刚跑完 LoadRunner 但对着数据没底的人。2. Vuser 脚本录制与事务划分登录、查询航班怎么拆才合理LoadRunner 的脚本是后续所有场景和报告的地基。脚本录得粗事务边界划得乱后面加再漂亮的图表也是错的。HP Web Tours 的三个核心交易——注册、登录、查询航班——每个的录制方式和事务切法都不一样需要单独处理。2.1 协议选型与 HTTP/HTML 录制模式HP Web Tours 是典型 B/S 系统客户端通过浏览器访问选Web (HTTP/HTML)协议即可。VuGen 新建脚本时勾选该协议录制级别建议用基于 HTML 的脚本而不是 URL 模式。原因是 HTML 模式下 LoadRunner 会把一个页面里所有资源请求自动合成一条web_url或web_submit_data脚本可读性和可维护性都更好URL 模式会把每个 gif、js 都录成独立请求后期回放容易因静态资源变动而误报失败。录制时容易踩的两个坑一是浏览器代理设置冲突常见做法是先关掉本地浏览器代理录制完成后再恢复二是录制过程中 View State、Session ID 这类动态值会被硬编码进脚本直接回放必然失败必须在录制后用关联Correlation替换。2.2 事务边界登录、查询分别是一笔还是两笔事务Transaction的粒度直接决定报告里响应时间的含义。这份报告里登录和查询航班被拆成独立事务是合理的因为两者在业务上对应不同的用户动作在性能上瓶颈也往往落在不同层。脚本里用lr_start_transaction/lr_end_transaction包裹Action() { // 静态资源无需单独计事务 web_url(WebTours, URLhttp://192.168.1.100:1080/WebTours/, Resource0, RecContentTypetext/html, Snapshott1.inf, ModeHTTP, LAST); // 登录事务边界从提交登录表单到跳转首页 lr_start_transaction(login_transaction); web_submit_data(login.pl, Actionhttp://192.168.1.100:1080/WebTours/login.pl, MethodPOST, RecContentTypetext/html, Refererhttp://192.168.1.100:1080/WebTours/nav.pl?inhome, Snapshott2.inf, ModeHTTP, ITEMDATA, NameuserSession, Value{userSession}, ENDITEM, Nameusername, Value{username}, ENDITEM, Namepassword, Value{password}, ENDITEM, Namelogin.x, Value52, ENDITEM, Namelogin.y, Value10, ENDITEM, LAST); // 用检查点确认登录真的成功而不是拿到了错误页 web_reg_find(TextWelcome, SaveCountlogin_count, LAST); lr_end_transaction(login_transaction, LR_AUTO); return 0; }逻辑说明lr_start_transaction与lr_end_transaction之间是事务的计时区间只有这段区间内的服务器处理时间才会被计入响应时间。LR_AUTO表示由 LoadRunner 自动判定事务通过还是失败。检查点web_reg_find必须注册在请求之前否则无法拦截响应内容。参数说明Resource0表示这条请求不计入页面资源统计仅作为页面跳转Snapshot用于回放失败时定位问题可以保留ModeHTTP是录制时的默认模式与 HTML 单元回放兼容。提示事务名不要用中文LoadRunner Controller 和 Analysis 对中文事务名的排序和筛选支持不稳定用英文小写下划线是最省事的做法。2.3 关联与参数化userSession 和用户资料的处理userSession是 HP Web Tours 每次登录后下发的动态值硬编码回放必然失败必须做关联。常见做法是在录制时打开“自动关联”或者在脚本里手动加web_reg_save_paramweb_reg_save_param(userSession, LBname\userSession\ value\, RB\, SearchBody, LAST);LB和RB是左右边界SearchBody指定只在响应正文里找。这个函数也必须放在产生该值的请求之前。用户数据则用参数化而不是每个 Vuser 硬编码一份账号密码。在 Parameter List 里建一个username参数表用UniqueOnce的组合每个 Vuser 取一行登录时用它填表单。这样 200 个并发用户就能模拟 200 个不同身份避免服务端会话互踢。2.4 回放验证与迭代次数确认脚本写完先单用户回放日志等级调到 Extended逐条核对每个请求的返回码和检查点。确认无误后把Run-time Settings里的 Run Logic 迭代次数设为 1先跑通。注册和查询航班两段脚本在报告里对应不同的事务名回放时应该分别看到login_transaction、register_transaction、query_transaction三条事务记录任何一条缺失或超时都要回脚本里找原因不要直接进 Controller 压测。3. 场景设计逐步加压、瞬间加压与 3 台 PC 的分工脚本能在单机回放通过只代表语法对了。真正决定报告可信度的是 Controller 里的场景配置。这份报告做了 200、400、700、1000 四个用户档位但真正跑出结果的是 200 并发那一档其配置思路值得展开。3.1 手动场景还是目标场景Controller 提供两种场景模型手动场景Manual Scenario和目标场景Goal-Oriented Scenario。目标场景是设定一个目标如 TPS 达到 100 或响应时间稳定在 5 秒内由工具自动调节并发用户数去逼近适合验收类测试手动场景是用户数、加压节奏、持续时间全部手工指定适合找瓶颈。这份报告用的是手动场景因为目的是“看系统在多大的压力下崩”而不是“验证系统能不能扛住 500 TPS”。两种场景在分析阶段的意义不同手动场景跑出来的吞吐曲线能让你看到拐点目标场景只能告诉你目标达成没达成。3.2 加压节奏逐步加压和瞬间加压怎么选报告里提到两种加压方式每隔 2 秒启动 1 个 Vuser以及一次性启动 10 个或 100 个。这两种方式在 Controller 里分别对应 Ramp-up 配置加压方式Controller 配置适用场景观察重点逐步加压Ramp-up 每 2 秒启动 1 Vuser找系统稳定吞吐上限TPS 拐点和响应时间跃变瞬时加压Ramp-up 设为 0同时启动模拟突发流量、开机洪峰短时错误率和恢复速度阶梯加压分批设置每批 50 用户定位在哪个并发量开始劣化各档位资源利用率对比逐步加压能明确看到“在多少用户数之后响应时间开始指数上升”这个拐点比最大 TPS 更有价值。瞬间加压则更考验连接池、线程池、数据库连接数的初值设置是否合理短时间内的错误率会显著高于逐步加压。3.3 分布式负载生成器的部署与分配报告里用了 3 台 PC 承载 200 个并发用户两台各 70 左右一台 60 左右并同时跑 Controller。这种部署在中小规模压测里非常常见但有两条硬约束要注意每台负载机Load Generator能承载的 Vuser 数受 CPU、内存和网络带宽限制。跑 Web (HTTP/HTML) 协议时单台 4 核 8G 的机器大概能稳定跑 80~120 个 Vuser具体要看每个 Vuser 的脚本复杂度。Controller 所在机器同时跑 Vuser 会拉高自身 CPU影响加压精度能分开就分开。负载机在 Controller 里通过Load Generators面板添加IP 填内网地址连接方式选默认的Agent或Remote Management每台机器要预装 LoadRunner Agent 并启动服务Windows 上防火墙需放行对应端口。配置完成后点Connect状态全绿才算就绪。3.4 场景运行与实时监控的采集项Controller 的Run视图里需要打开几个关键图Running Vusers当前并发数、Transactions per SecondTPS、Average Transaction Response Time平均响应时间、Errors per Second错误数。AP 服务器和 DB 服务器的资源指标用 LoadRunner 自带的Web Resource Monitor或Windows Resource Monitor采集 CPU、Memory、Disk 计数器。这次报告里能拿出User% / Sys% / Wait%的三段数据就是因为提前在 Controller 里配好了 Windows 资源监控指向了两台主机的性能计数器。没配这一层后面分析就只能看业务层找不出到底是 CPU 满还是 IO 排队。3.5 场景持续时间与失败退出策略200 并发逐步加压大约 7 分钟到满报告里第一次跑了 30 分钟就崩是因为没有配事务失败比例触发停止。常见做法是在 Controller 的Scenario Schedule里加一个Stop scenario if transaction failure percentage exceeds X%比如设成 20%一旦登录事务大面积超时就能自动停在可分析的节点而不是等它跑成一锅粥。第二次稳定跑到 50 分钟是因为登录操作被提前收口后面所有交易共用同一会话脚本负载特征发生了根本变化。4. 指标采集与瓶颈定位从 AP 的 CPU 100% 拆到 DB 的 IO 等待报告出来之后最有价值的工作是回答三个问题哪个事务慢、慢在哪一层、下一轮该改什么。把两次测试的数据摊开对照答案就很清楚了。4.1 业务级指标响应时间、TPS、成功率业务层指标从 Analysis 里直接取三个口径必须说清楚平均响应时间所有成功事务的平均值容易被大量快事务拉低配合 90% 分位或最大值一起看。TPS单位时间内完成的事务数注意区分“成功 TPS”和“发起 TPS”报告里写的吞吐率应是成功交易量除以统计时段。成功率成功事务数除以发起事务数报告里给的期望值是大于 95%这个门槛对订票类业务是合理的。第一次测试里 AutoUW_Transaction 平均响应 3.73 秒、最大 387.87 秒这个最大值意味着链路里存在长时间的阻塞不是简单的高负载排队。第二次测试里 GeneralQuery_Transaction 平均 11 秒、最大 35 秒属于可接受的劣化。这种差异化才是分析要抓的重点。4.2 系统级指标AP 与 DB 两端的 CPU 与 IO 对照报告里 AP 服务器两次都跑到 95% 以上DB 服务器第一次 CPU 很低、IO 等待反而高第二次 CPU 上到 75%。这个组合说明第一次 AP 满、DB 闲说明瓶颈在应用层登录操作过于频繁导致 AP 端的会话处理、加密校验吃掉了 CPU业务请求根本到不了数据库。第二次 AP 依然满、DB CPU 上升、IO 等待依然高说明请求真正打到了数据库层数据库成了第二段瓶颈慢在物理 IO 上。把 AP 和 DB 两端数据放在一张表里对照比各画一张趋势图更能说服人阶段AP CPUDB CPUDB IO 等待明显慢的事务第一次1:52–2:20~100%20%较低登录相关全部超时第二次2:45–4:0095%75%较高Audit、ClaimRegister4.3 两次测试流程差异带来的数据解读两次测试唯一的变量是登录流程但因为登录是一个非常“重”的操作会话创建、密码校验、跳转它在 200 并发下的开销不可忽略。第一次每笔交易前都登录相当于把登录的负载乘以了交易次数AP 端 CPU 被反复叫醒做同一件事事务成功率自然崩塌。第二次改成每个 Vuser 只登录一次登录开销从“每交易一次”变成“每 Vuser 一次”AP 压力下降请求真正到达数据库于是 DB 端的 CPU 和 IO 都跟着上来了。从性能测试角度第二次的结果才是有效结果第一次只能作为“登录设计缺陷”的佐证。注意脚本流程变化后必须重新校准基线否则两次数据之间没有可比性。报告里把两次结果并列展示是对的但在结论里必须明确哪一次代表系统真实能力。4.4 慢事务定位Audit_Transaction 与 ClaimRegister_Transaction第二次测试里最扎眼的是两类交易Audit_Transaction 平均 162 秒、最大 207 秒ClaimRegister_Transaction 平均 143 秒、最大 163 秒。这两个事务的响应时间在整段测试中始终居高不下没有随登录完成而回落说明它们的慢与并发数无关是稳态慢事务。排查这类事务的常用套路在 Analysis 里打开Transaction Response Time (Percentile)图确认慢的是所有采样点还是尾部少数点。如果 90% 分位也远高于平均说明是脚本级的普遍慢如果只是平均值被拖高说明是长尾。打开Web Page Breakdown或Page Download Time Breakdown看时间花在 First Buffer、Receive 还是 Client Time。如果 Client Time 占比高问题可能在脚本本身的思考时间或参数化取数。在 AP 端开数据库慢查询日志把这两个事务对应的 SQL 抓出来常见原因是缺索引、全表扫描或锁等待。用Web Resource Monitor对比这两个事务执行时段的 DB 锁资源数量如果锁等待明显上升说明事务隔离级别或提交时机有问题。报告里提到这两个事务“超时严重、成功率很低”基本可以判断它们卡在数据库层。下一轮调优应该先做 SQL 审查和索引补齐而不是继续加机器。5. 从报告到落地登录复用、参数化与慢事务剥离的调优技巧性能测试最终要回答的是“下一步怎么改”。HP Web Tours 这套流程跑过两轮之后最值得复用的三个技巧是脚本层的登录复用、数据层的参数化隔离以及报告层的慢事务单独分析。下面按可复现的粒度展开。5.1 脚本层登录只跑一次交易循环复用会话登录复用是最直接有效的一招。实现方式是在脚本里用vuser_init段执行登录把userSession存到全局参数里Action段循环执行查询或业务交易不再重复登录vuser_init() { web_url(WebTours, ..., LAST); lr_start_transaction(login_transaction); web_submit_data(login.pl, ..., LAST); lr_end_transaction(login_transaction, LR_AUTO); // userSession 通过关联存到参数后续 Action 里复用 return 0; } Action() { // 复用初始化阶段拿到的 userSession只循环发查询交易 lr_start_transaction(query_transaction); web_submit_data(itinerary.pl, ..., LAST); lr_end_transaction(query_transaction, LR_AUTO); return 0; }这样每个 Vuser 只承担一次登录开销报告中业务层响应时间更能反映真实业务能力。vuser_init在整个场景中每个 Vuser 只执行一次Action才按迭代次数循环。5.2 数据层参数池按 Vuser 隔离避免账号互踢参数化时优先选Unique Once的组合每个 Vuser 从参数表里取一行独占使用避免多个 Vuser 抢同一个账号导致服务端会话互斥。如果业务账号不够可以退一步用 Unique Each iteration让每次迭代取不同的值但要确认服务端允许多会话并存。参数表里建议额外加一列状态备注压测完可以回溯哪个账号在哪个时段报错。5.3 报告层慢事务单独建图、单独下结论分析时把慢事务从总体平均线里剥离出来单独建图。Analysis 里右键Add New Graph→Transaction Response Time筛选出 Audit_Transaction、ClaimRegister_Transaction再和Running Vusers双 Y 轴叠加能直观看到它们的响应时间和并发数是否相关。如果两条曲线不平行说明慢是业务本身的问题如果平行上升说明是资源竞争。最终报告里“平均响应时间 15s、成功率 95%”这类期望值必须按事务分别列出实测值不能用一个总数概括全局否则慢事务永远会被快事务的平均值掩盖。本文还有配套的精品资源点击获取