事务响应时间是测量系统性能的重要标准。LoadRunner通过事务（Transaction）来测量和定义它。理解组成、测量方法和优化点，准确定位性能短板。

事务响应时间分解

一个事务从客户端发起请求到接收到完整响应，总时间并不是单一的服务处理时间，是由网络时间、服务器处理时间和客户端时间三大部分组成。

总响应时间 = 网络传输时间 + 网络延迟 + 服务器处理时间(WT+AT+DT) + 客户端渲染时间

网络时间和网络延迟

网络传输时间(N1~N6)：数据包在各级网络设备间传输的时间。包括从客户端到Web服务器(N1)、Web服务器到应用服务器(N2)、应用服务器到数据库(N3)及其返回途径(N4, N5, N6)。

网络延迟：数据包排队、交换等产生的等待时间。

影响前端网络的原因：DNS分析时间、建立连接时间、SSL握手时间、收到第一个字节的时间、内容下载时间等。

服务器处理时间

发生在系统后端：

Web服务器时间(WT)：处理静态文件、转发请求、执行压缩等。

应用服务器时间(AT)：执行业务思路、调用EJB/服务、访问JNDI等。

数据库服务器时间(DT)：建立JDBC连接、分析SQL、执行查询、返回结果。

客户端时间

浏览器或客户端应用分析、渲染响应内容所花费的时间。在性能测试中，一般更重视服务器端响应时间，可通过设置忽略客户端思考时间或渲染时间来获得。

在LoadRunner中标记和测量事务

在VuGen脚本中，使用 lr_start_transaction 和 lr_end_transaction 函数来标记事务的起止。

c

// 标记“登录”事务开始

lr_start_transaction("Login");

    web_url("login.do", 

        "URL=http://example.com/login.do", 

        "Resource=0", 

        "RecContentType=text/html", 

        LAST);

// 标记“登录”事务结束，LR_AUTO表示自动判断成功和否

lr_end_transaction("Login", LR_AUTO);

事务配置：

位置：事务应标记在Action部分，vuser_init和vuser_end中的事务默认在情形中可能不被执行或统计。

粒度：不宜过大或过小。如，将登录-查询-登出作为一个事务，就难以定位具体哪一步慢。应拆分为多个事务。

嵌套：支持事务嵌套，便于分析子步骤。如在下单主事务内嵌套添加购物车、支付等子事务。

状态判断：不要完全依赖LR_AUTO。应结合业务思路使用lr_end_transaction("Login", LR_PASS/FAIL)手动判断。如，检查登录后页面是不是包含用户名。

保证记录：在Controller的Run-time Settings中，需勾选Collect transaction response time以保证事务数据被收集。

关联、思考时间和SLA

关联函数对时间的影响：类似 web_reg_save_param_ex 的注册类函数必须放在请求之前。在接收到服务器响应时执行，执行时间会计入下一个事务，而不是当前事务。放置位置错误会导致时间统计失真。

思考时间(Think Time)：模拟用户操作间隔。在分析服务器纯处理能力时，可在Controller中忽略思考时间。

定义服务水平协议(SLA)：在Analysis中可根据事务响应时间定义SLA。如，设定登录事务的响应时间在3秒内为优秀，3-5秒为可接受，超过5秒则为违规。测试报告会自动统计达标率。

百分比分析：Analysis提供90 Percent等标准，表示90%的用户响应时间低于该值。这比平均响应时间更能体现大多数用户的体验。

结果分析

在Analysis中查看事务性能图时结合其他监控标准进行关联分析：

如果所有事务响应时间都随负载增加而线性上升，可能为网络带宽或应用服务器处理能力短板。

如果仅某个涉及数据库操作的事务变慢，且数据库服务器的CPU或磁盘I/O监控标准异常，则短板很可能在数据库。

通过将总响应时间和Time to First Buffer（网络时间）等细分标准对比，可以快速判断问题是出在网络传输还是服务器处理上。

为每个业务操作建立独立、命名清晰的事务，并结合分层监控（网络、服务器、数据库），是准确定位性能短板、出具专业测试报告的不二法门。