开发者常常担心 Temporal 会给他们的应用程序增加延迟。Temporal 提供了各种特性和工作流设计模式来帮助您满足大多数应用程序的延迟要求，但最终，您的最低延迟将取决于您的 Worker 与 Temporal Service 之间的网络延迟，以及 Temporal Service 的调优程度。
您可能认为，如果您使用 Temporal Cloud 而不是自托管 Temporal，您的应用程序延迟会更高。毕竟，使用 Temporal Cloud，Temporal Service 将不再位于与您的 Worker 相同的基础设施上，从而增加网络延迟。
实际上，情况恰恰相反：与自托管 Temporal 相比，使用 Temporal Cloud 的端到端应用程序延迟明显更低。Temporal Cloud 提供了重要的架构改进来降低延迟，包括一个 定制持久化层。Temporal Cloud 架构中的延迟改进非常有效，以至于超过了与 Temporal Cloud 通信所产生的更高网络延迟的成本。
我们经常注意到，当客户从自托管 Temporal 迁移到 Temporal Cloud 时，延迟得到了改善。为了量化这些观察结果，我们对应用程序侧指标进行了基准测试，将其与自托管 Temporal Service 和 Temporal Cloud 进行比较，应用程序 Worker 托管在同一区域。
结果表明，与自托管实例相比，Temporal Cloud 的延迟更低，这支持了我们经常告诉客户的内容：Temporal Cloud 是互联网规模和低延迟工作负载的最佳选择。
基准测试概述和设置#
我们测量了五个应用程序侧的 SDK 指标，我们之所以选择这些指标，是因为它们会影响应用程序延迟。Temporal 的 SDK 默认情况下会发出这些指标。
基准测试基础设施是使用专门的延迟基准测试框架建立的，该框架可在此处访问：https://github.com/temporalio/benchmark-latency。该框架构建了一个 Kubernetes 集群并部署了 Omes，这是我们用于基准测试和负载测试的指定工具。Omes 包含 Temporal Worker 和场景运行器，以模拟应用程序环境。
为了评估范围广泛的 SDK 指标，我们使用了 Omes 场景“throughput_stress”，该场景使用了全面的 Temporal 原语。 “throughput_stress” 工作流使用的活动轻量级，所需的 CPU 很少。由于此基准测试侧重于延迟而不是吞吐量，因此该场景配置为跳过睡眠并一次只运行一个工作流。使用此配置，工作流的端到端延迟可以作为比较 Temporal Service 实例的有效指标。
在基准测试期间，所有 Pod、节点和数据库的 CPU 利用率均低于 80%。
对于自托管 Temporal Service 的测试，该工具会安装一个由 MySQL 数据库支持的 Temporal Service。
本文中的所有测量结果均记录在 AWS us-west-2 区域中运行的集群中。
指标 1：WorkflowEndtoEnd 延迟#
它测量的内容： Workflow_EndtoEnd_Latency 测量从计划到完成的单个工作流执行的总执行时间。
我们对其进行基准测试的原因： 该指标可用于快速比较运行相同工作负载的实例的性能，因为它显示了完整执行的延迟。
结果
| p50 延迟 | p90 延迟 | |
|---|---|---|
| 自托管 Temporal | 750 毫秒 | 950 毫秒 |
| Temporal Cloud | 376 毫秒 | 476 毫秒 |
指标 2：StartWorkflowExecution 延迟#
它测量的内容：启动工作流请求的往返时间。要启动工作流，您的应用程序会联系 Temporal Service。Temporal Service 会持久化记录以表示工作流，并使用响应回复您的应用程序。由于请求已持久化，Temporal Service 无需等待工作流开始执行即可响应。
我们对其进行基准测试的原因：此指标很重要，因为应用程序倾向于频繁启动工作流，通常是内联处理 Web 请求的结果。保持此延迟低对于避免阻止 Web 请求至关重要。
结果
| p50 延迟 | p90 延迟 | |
|---|---|---|
| 自托管 Temporal | 23.8 毫秒 | 42.6 毫秒 |
| Temporal Cloud | 17.7 毫秒 | 23.8 毫秒 |
指标 3：SignalWorkflowExecution 延迟#
它测量的内容：向工作流发出信号请求的往返时间。与启动工作流请求一样，这些必须由 Temporal Service 持久化以确保不会丢失。
我们对其进行基准测试的原因：应用程序使用信号通知工作流外部事件。这些信号通常作为 UI 中的某个操作的结果或在消息队列上接收事件而传递。这里的低延迟有助于保持应用程序的响应速度并提高消息队列效率。
结果
| p50 延迟 | p90 延迟 | |
|---|---|---|
| 自托管 Temporal | 17.5 毫秒 | 23.5 毫秒 |
| Temporal Cloud | 7.64 毫秒 | 9.76 毫秒 |
指标 4：RespondWorkflowTaskCompleted 延迟#
它测量的内容：Worker 向 Temporal Service 响应工作流 Task 完成的时间。随着工作流的进展，Worker 必须与 Temporal Service 通信，详细说明接下来必须采取哪些操作。这可能是启动新的子工作流、调度活动，或者只是设置计时器以稍后唤醒工作流。
我们对其进行基准测试的原因：工作流吞吐量受 Worker 与 Temporal Service 通信速度的影响。如果 Temporal Service 响应更快，则 Worker 性能会提高，进而提高应用程序性能。
结果
| p50 延迟 | p90 延迟 | |
|---|---|---|
| 自托管 Temporal | 23.9 毫秒 | 51.5 毫秒 |
| Temporal Cloud | 17.8 毫秒 | 24.7 毫秒 |
指标 5：RespondActivityTaskCompleted 延迟#
它测量的内容：Worker 向 Temporal Service 响应活动任务完成的时间。
我们对其进行基准测试的原因：工作流吞吐量受 Worker 与 Temporal Service 通信速度的影响。活动用于执行单个明确定义的动作，例如调用另一个服务或处理数据。如果 Temporal Service 响应更快，则 Worker 性能会提高，进而提高应用程序性能。
结果
| p50 延迟 | p90 延迟 | |
|---|---|---|
| 自托管 Temporal | 23.9 毫秒 | 61.7 毫秒 |
| Temporal Cloud | 17.3 毫秒 | 30.8 毫秒 |
延迟差异分析#
此基准测试支持我们观察到的客户迁移后的情况：Temporal Cloud 提供比自托管 Temporal 更低的应用程序端延迟。Temporal Cloud 在所有方面的较低延迟降低了我们测试工作流的端到端延迟。Temporal Cloud 能够以自托管实例的 50.1% 的时间完成工作流，在 p50 和 p90 上均如此。
这些延迟改进可归功于 Temporal Cloud 的 定制持久化层，该层包括更高效的分片、写前日志 (WAL) 和分层数据存储。我们专门为高吞吐量和大规模设计了此架构。正如本基准测试所示，定制持久化层的优势远远超过使用 Temporal Cloud 时产生的任何网络延迟。
此基准测试对生产应用程序的意义#
数千名用户目前在生产环境中运行使用自托管 Temporal 和 Temporal Cloud 的应用程序。我们的建议是，您应该考虑为所有生产工作负载使用 Temporal Cloud，因为其具有 服务级别保证和 支持——特别是对于延迟敏感、大规模或关键业务应用程序。
最终的考虑因素是，Temporal Cloud 比自托管 Temporal 提供更低的性能价格比。在此基准测试中，自托管 Temporal Service 经过了良好的调优，并且从未使用过载（始终低于 80% CPU）。实际上，情况并非总是如此。 扩展 Temporal Service 以用于高吞吐量用例可能需要大量工作。您必须扩展数据库（Postgres、MySQL 或 Cassandra）并管理四个额外的独立服务。数据库和所有服务必须得到适当的资源配置：为峰值负载配置，以避免瓶颈，并以高度可用方式部署。与 按使用量付费的成本相比，这些基础设施和运营成本很高 Temporal Cloud。
了解更多信息并自行运行基准测试#
我们提供了有关如何重现此基准测试的详细信息 https://github.com/temporalio/benchmark-latency。与任何基准测试一样，结果可能会因您的工作负载和规模而异。
以下是一些其他有用的资源，以了解更多信息
- 博客文章 – 更高的吞吐量和更低的延迟：Temporal Cloud 的定制持久化层
- 按需网络研讨会 – Temporal Cloud 的定制持久化层
- 视频 – Replay 会议的定制持久化层演讲
- 博客文章 – 扩展您的自托管实例