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