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