LoadRunner报错26697：原因分析与解决方案
在使用LoadRunner进行性能测试时，许多用户可能会遇到错误代码26697，提示类似“Error -26697: No response received for request”的信息，这类报错通常与HTTP请求未收到服务器响应相关，可能影响测试结果的准确性，本文将从错误原因、排查步骤到解决方案，提供系统化的处理思路，帮助用户快速定位问题。
**一、错误现象与常见场景
错误26697的核心问题是客户端（VuGen脚本）未在指定时间内收到服务器响应，常见触发场景包括：
1、高并发测试中服务器处理延迟，导致响应超时；
2、被测系统存在性能瓶颈（如数据库连接池耗尽）；
3、网络环境不稳定（如防火墙拦截、带宽不足）；
4、脚本协议配置错误（例如未正确设置HTTP请求参数）。
该错误可能单独出现，也可能伴随其他报错（如超时、连接中断），需结合日志进一步分析。
**二、核心原因排查方法
**1. 检查服务器与网络状态
监控服务器资源：通过工具（如Windows性能计数器、Linux的top命令）查看CPU、内存、磁盘I/O是否达到瓶颈；
网络抓包分析：使用Wireshark或Fiddler确认请求是否正常发送，服务器是否返回数据；
防火墙与代理配置：排查是否因安全策略拦截了请求或响应。
**2. 验证脚本协议配置
确认协议兼容性：若被测系统使用WebSocket或HTTP/2，需确保VuGen选择对应协议；
检查请求超时参数：在Run-time Settings > Preferences > Options中，调整HTTP-request connect timeout和Receive timeout值（默认值可能过小）；
处理动态参数依赖：若请求中包含动态生成的Token或会话ID，需检查关联函数是否正确提取。
**3. 优化负载生成策略
降低并发用户数：逐步增加负载，观察服务器响应时间变化；
添加思考时间（Think Time）：模拟真实用户操作间隔，避免服务器瞬时压力过大；
启用资源池限制：例如限制数据库连接数，避免资源争抢。
**三、针对性解决方案
**方案1：调整超时参数
LoadRunner默认超时设置可能无法适应高延迟场景，需手动扩展：
1、打开VuGen脚本，进入Run-time Settings > Preferences > Options；
2、找到HTTP-request connect timeout和HTTP-request receive timeout，将数值从默认的120秒调整为更高值（如300秒）；
3、若仍报错，可尝试在注册表中修改全局超时配置（需谨慎操作，建议备份注册表）：
- 定位到HKEY_CURRENT_USER\Software\Mercury Interactive\LoadRunner；
- 新建DWORD值，命名为HttpRequestTimeout，设置数值为十进制超时时间（单位：秒）。
**方案2：修复脚本逻辑问题
检查请求头与Cookie：缺失必要的Header（如Content-Type、Authorization）可能导致服务器拒绝响应；
禁用冗余重定向：在Run-time Settings > Internet Protocol > Preferences中勾选Support redirect，避免因多次跳转而超时；
添加错误处理函数：在脚本中插入web_set_sockets_option("SSL_VERSION", "TLS")或web_reg_save_param捕获响应，增强容错能力。
**方案3：优化被测系统性能
数据库调优：检查慢查询日志，优化索引或拆分大表；
启用缓存机制：通过Redis或Memcached缓存高频访问数据；
扩容服务器资源：增加应用服务器的线程池大小或横向扩展集群节点。
**四、预防措施与最佳实践
1、预测试环境校准：确保测试环境与生产环境配置一致（包括网络带宽、中间件版本）；
2、分阶段加压策略：先进行单用户脚本验证，再逐步增加并发，定位性能拐点；
3、日志与监控联动：实时监控服务器指标，结合LoadRunner的Diagnostics模块分析事务响应时间；
4、协议与参数标准化：针对REST API、SOAP等不同协议，明确脚本的参数化规则。
**个人观点
错误26697虽常见，但本质是系统性能或脚本逻辑问题的“信号灯”，处理时需避免盲目修改超时参数，而应结合场景深入分析底层原因，在实际测试中，建议团队建立标准化的排查流程，例如先验证单请求成功率，再逐步构建复杂场景，性能测试不仅是工具的使用，更依赖于对系统架构的理解与持续优化。
