我目前正在开发负载运行程序脚本，用于对以异步模式处理的应用程序进行性能测试。我正在进行性能测试的应用程序通过 SFTP 接受输入文件，并通过 SFTP 在输出位置发送处理后的输出。
为了构建脚本来衡量应用程序的性能，我打算使用两个 Vugen 脚本，一个用于提交输入文件，另一个用于接收输出文件。为了测量输入和输出之间的持续时间，我想使用 Cross Vugen Transaction。
我已经阅读了用户指南中的文档，但这对我来说太少了，无法理解和实施。您能否提供一个示例脚本或更详细的步骤来说明如何实施、执行和查看 Cross Vugen 事务。
请注意，我是 vugen 脚本的初学者，非常感谢您提供这方面的任何帮助。
【问题讨论】：
您将不得不手动处理如何将哪个起始交易与哪个结束交易相关联。 Loadrunner 本身不这样做。
一种方法可能是将事务 ID 及其开始日期/时间插入到第一个脚本中的 VTS 表中。然后第二个脚本从同一个表中读取，找到匹配的事务 ID，然后使用 lr_user_data_point() 记录自定义事务时间。
或者，如果有某种方法可以在事后获取开始时间，例如在输出文件中读取“创建”时间戳值以获取开始时间 - 然后您可以计算第二个脚本中的时间差并使用lr_custom_data_point().
如果所有其他方法都失败了，最简单的方法是将所有内容保存到两个日志文件中，稍后手动计算时间差。
【讨论】：
有一个函数 lr_start|end_distributed_transaction() 旨在直接处理这种情况。但是，如果你对 LoadRunner Yahoo Group 和 lr-LoadRunner google group 都做一些研究，你会发现这个函数在操作上是不一致的。有几种替代路径
正如 Michael Galos 所指出的，您可以使用 VTS、RabbitMQ、Amazon Simple Queue Service、传统数据库中的队列表等将信息放在脚本之间的代理上……然后第二个用户可以在开始时间（理想情况下以 unix 时间毫秒为单位），计算与当前时间的差异，然后使用 lr_set_transaction() 函数动态创建事务。该模型确实存在一些问题，因为它假定从一个虚拟用户到另一个虚拟用户的最大队列深度为 1，没有延迟，并且假定从队列中弹出的下一个项目将是正确的项目，这在异步模型。
您还可以在正在处理的记录中使用所谓的标记数据。例如，如果您的记录允许使用数字而不是中间名，例如，请考虑使用 unix 时间戳作为中间名。然后，只要您拉出您的记录，您就会拥有一份较早放入队列时的原始时间副本。这也避免了必须集成额外的基础设施。将开始时间作为原始记录的一部分，将结束时间作为本地虚拟用户的一部分，您可以再次使用 lr_set_transaction() 动态创建交易。
最佳情况是后端数据库跟踪处理异步请求所需的时间。让我们假设记录一旦到达，就需要多个处理阶段。跟踪各个阶段的到达时间的审计跟踪可用于在测试结束时生成一组数据点，然后可以将其作为测试报告的一部分拉入 Analysis。这不仅可以提供最佳的处理时间，因为您将看到从到达一个队列到放置在出站队列以供取件的时间视角（没有客户端处理或网络的延迟）。当元素“卡住”时，此类审计跟踪还有助于生产调试。作为替代方案，您还可以处理可能收集此信息的日志。我喜欢在这个过程中使用 Splunk，但其他人使用 ELK 堆栈甚至 Microsoft Logparser。导出到分析中提取的数据点（数据库审计跟踪、Splunk、ELK 或 LogParser）的查询确实成为分析和呈现的最优雅的解决方案。
这是你在这一切中的弱点。您的系统时钟。确保您的所有系统时钟在您将从中提取时序数据的所有虚拟用户负载生成器和主机上同步。如果您在虚拟机环境中，这将成为问题，因为虚拟机将使用最终必须与物理系统时钟同步的虚拟化系统时钟。这可能会导致时钟跳变，从而导致时间记录看起来比硬件时钟环境中的时间记录更长。这样做的结果是，您将拥有更高的平均、最大值、标准偏差和 90th/95th 百分位响应时间。您可以通过在循环中使用几个硬件负载生成器作为控制元素来应对这种意外情况，然后使用该集合的时间记录作为对虚拟化负载生成器中任何偏差的控制。值得深思。
【讨论】：