--- title: "性能" description: "单个 Dex Server 节点在 AWS 上使用 S3 时的实测吞吐和延迟，SYNC 和 ASYNC Step 各自的开销，运行成本，以及如何复现结果。" canonical_url: "https://docs.superdurable.io/zh-Hans/intro/performance/" source: "docs/i18n/zh-Hans/docusaurus-plugin-content-docs/current/intro/performance.mdx" locale: "zh-Hans" --- > 供 AI Agent 使用的全部页面索引：https://docs.superdurable.io/zh-Hans/llms.txt # 性能 本页给出单个 Dex Server 节点的实测数据和运行成本。 ## benchmark 怎样运行 下面的数据于 2026-11-09 在 AWS us-west-2 测得： - **Server：** 一个 Dex Server 节点，运行在 c7gd.large（2 vCPU）或 c7gd.4xlarge（16 vCPU）上。本地存储在实例的 NVMe 磁盘上。日志写入同一 Region 的 S3 Standard。 - **负载：** 同一可用区里另一台 c7g.8xlarge 运行 benchmark 工具和一个 Go SDK Worker。它的 CPU 一直低于 38%。 - **版本：** Step、Flow 和 Channel 唤醒使用 Dex Server（server-zd）v0.1.23；RPC 和读取使用 v0.1.25。 - **运行方式：** 每个测试点在一个新 server 上先预热 10 秒，再测量 45 秒。大多数测试点运行三次，表中给出中位数。Flow 启动的每个测试点只运行一次。 - **负载模型：** 固定数量的并发 client，每个 client 在上一个请求返回后发送下一个请求。server 繁忙之后，延迟随 client 数增长。 每次运行及其设置都在 [benchmark 结果目录](https://github.com/superdurable/dex/tree/main/benchmark/results)里，[复现结果](https://docs.superdurable.io/zh-Hans/intro/performance.md#reproduce-a-result)说明怎样重跑其中一次。 ## 峰值吞吐 | 操作 | c7gd.large | c7gd.4xlarge | | ---------------------------------- | ----------: | -----------: | | SYNC Step | 每秒 1,772 个 | 每秒 8,403 个 | | ASYNC Step | 每秒 2,105 个 | 每秒 10.1k 个 | | 启动并完成的 Flow，每个一个 Step | 每秒 1,111 个 | 每秒 5,626 个 | | 读取一个 Attribute 的 RPC | 每秒 15,392 个 | 每秒 67.3k 个 | | 加锁并更新一个 Attribute 的 RPC | 每秒 2,165 个 | 每秒 13.8k 个 | | 读取十个 16 KiB 的 Attribute，不经过 Worker | 每秒 5,941 次 | 每秒 11.3k 次 | | 唤醒等待中 Step 的 Channel 消息 | 每秒 460 条 | 每秒 2,278 条 | ## 峰值以下的延迟 这些行在大约一半的峰值吞吐下运行。延迟单位是毫秒。每行的 client 数不同，延迟随它增长。SYNC 行在 c7gd.large 上用 96 个 client，在 c7gd.4xlarge 上用 1,024 个。所以较大节点的 SYNC 延迟更高，是因为它承担了十倍以上的负载，而不是因为它更慢。 | 操作 | 实例 | 吞吐 | p50 | p99 | | -------------------- | ------------ | ---------: | --: | --: | | SYNC Step | c7gd.large | 每秒 846 个 | 105 | 285 | | SYNC Step | c7gd.4xlarge | 每秒 4,527 个 | 218 | 382 | | ASYNC Step | c7gd.large | 每秒 1,224 个 | 1.3 | 4.9 | | ASYNC Step | c7gd.4xlarge | 每秒 4,766 个 | 1.6 | 3.3 | | 读取一个 Attribute 的 RPC | c7gd.large | 每秒 7,501 个 | 0.5 | 0.9 | | 读取一个 Attribute 的 RPC | c7gd.4xlarge | 每秒 35.0k 个 | 0.6 | 2.1 | | Channel 唤醒 | c7gd.4xlarge | 每秒 1,400 次 | 139 | 308 | Channel 唤醒的吞吐包含每次发布前不计时的准备工作。只有它的延迟，即从发布到被唤醒的 Step 开始运行，衡量的是 Dex。 ## 这些数据说明什么 - **SYNC Step 要等 S3。** 一个 SYNC Step 要等两次日志提交：它的尝试开始和它的结果。每次提交是一次 S3 PUT，一次提交可以携带许多 Flow 的命令。在 SYNC 峰值下，一次提交平均耗时 41 到 98 毫秒。有负载时，SYNC Step 还要等它所在的批次，所以它需要很多并发 Flow 才能达到峰值吞吐。 - **一个 Flow 会多出多少时间。** 在 c7gd.large 的半峰值负载下（96 个并发 client），一个 SYNC Step 的 p50 是 105 毫秒。所以一个依次运行五个 SYNC Step 的 Flow，大约要花半秒等待 Dex 提交，再加上你自己代码的时间。Agent Session 用 SYNC Step 处理模型调用和 Tool Call，所以每次调用都给一轮对话增加一次提交。 - **低负载时。** benchmark 没有在低负载下测量 SYNC Step。轻负载下的 SYNC Step 仍然要等两次提交，即开始和结果，所以一个等待 `Charge` 的 handler 会先后经历大约两次对象存储写入，再加上你自己代码的时间。这些写入在峰值下平均 41 到 98 毫秒；低负载时，预计为你所用对象存储的单次写入延迟。这是估算，不是测量结果。 - **ASYNC Step 立即继续。** Flow 在提交之前就继续往下走，所以低负载时一个 Step 耗时 1 到 2 毫秒。[SYNC 和 ASYNC Step](https://docs.superdurable.io/zh-Hans/concepts/step/advanced-guarantees.md#sync-and-async) 解释其中的取舍。 - **S3 请求数跟随批次，而不是 Step。** Dex Server 把写入合并成日志批次。一个繁忙节点每秒发出 23 到 98 次日志 PUT，与节点大小无关。按每 1,000 次 PUT 0.005 美元计算，每个节点每繁忙一小时最多约 1.8 美元。空闲节点每秒约 0.3 次 PUT，用于续约 lease。 - **CPU 是瓶颈。** 2 vCPU 节点在每个峰值下都用了 93% 到 99% 的 CPU。16 vCPU 节点在大多数峰值下用了 68% 到 87% 的 CPU。16 vCPU 节点读取大 Attribute 时，瓶颈则是它 15 Gbps 的网络。 - **读取需要的只有 Dex Server。** RPC 在 Worker 上运行。直接读取 Attribute 只访问 Dex Server，不需要 Worker。 - **这些峰值是一个集群的上限。** 一个集群由一个 active 节点服务。[限制](https://docs.superdurable.io/zh-Hans/intro/limits.md#capacity-and-availability)介绍这个上限、故障转移和升级。 ## 运行成本 Dex Server 需要一台实例、一台可选的 standby 实例，以及对象存储。实例和存储的字节数按你的云服务商价格计算。S3 请求数可以从上面的数据推算，按每 1,000 次 PUT 0.005 美元计： | 场景 | 每秒 PUT 次数 | 每 30 天 PUT 次数 | 每月 PUT 费用 | | --------------- | --------: | ------------: | ---------: | | 空闲节点，只续约 lease | 约 0.3 | 约 78 万 | 约 4 美元 | | 繁忙节点，实测范围的下限 | 23 | 约 6,000 万 | 约 300 美元 | | 繁忙节点，整月保持实测最高速率 | 98 | 约 2.54 亿 | 约 1,270 美元 | 大多数部署落在前两行之间，因为节点只在部分时间里繁忙。 一个轻负载的例子：每月 100 万个订单，每个订单是一个包含五个 SYNC Step 的 Flow，共 500 万个 Step。一个 SYNC Step 保存它的开始和结果，每次日志提交是一次 PUT。轻负载下一个批次很少包含超过一次提交，所以上限约为每个 Step 2 次 PUT：1,000 万次 PUT，每月约 50 美元，再加上约 4 美元的 lease 续约费用。负载更重时，多次提交会共用一个批次，每个 Step 的成本随之下降。每月总费用包括： - 实例：active 节点，如果运行 standby 再加上它，按云服务商的每小时价格计算； - PUT：上面的估算，或者节点一直繁忙时表中对应的行； - 存储的字节数：保留期内留存的 run，按云服务商的价格计算。benchmark 没有测量每个 Flow 存储的字节数。已关闭的 run 在[保留期](https://docs.superdurable.io/zh-Hans/components/production.md#defaults-to-change-before-production)之后被删除，所以存储量取决于这段时间内的 run 数。 ## 复现结果 [benchmark/aws](https://github.com/superdurable/dex/tree/main/benchmark/aws) 里的脚本可以在你自己的 AWS 账号上重跑一个已记录的测试点。你需要： - AWS CLI v2 和 `openssl`，以及一个能管理 EC2、S3 和 IAM 的 profile； - 该 Region 中的一个 EC2 密钥对； - `dexbench` 和 `dex-server-zd` 的 Linux arm64 构建，在 Ubuntu 24.04 arm64 上构建，与主机一致。 在同一个可用区里启动共享资源、一台 server 和一台负载主机： ```bash export DEXBENCH_RUN_ID= DEXBENCH_AWS_PROFILE= DEXBENCH_AWS_REGION=us-west-2 export DEXBENCH_AZ=us-west-2b DEXBENCH_KEY_NAME= benchmark/aws/launch.sh infra DEXBENCH_SERVER_INSTANCE_TYPE=c7gd.large benchmark/aws/launch.sh server DEXBENCH_MARKET=on-demand DEXBENCH_LOAD_INSTANCE_TYPE=c7g.8xlarge benchmark/aws/launch.sh load ``` 然后从一组已记录的结果里重跑一个测试点。脚本从这次运行的 `config.env` 和 `points.txt` 读取设置；省略场景和 client 数，就会重跑所有测试点： ```bash benchmark/aws/reproduce.sh benchmark/results/ sequential-steps 512 ``` 完成后删除所有资源。这些实例也会在两个半小时后自行关机。 ```bash benchmark/aws/teardown.sh ``` ## 发布状态和许可证 [限制](https://docs.superdurable.io/zh-Hans/intro/limits.md#release-status)给出 Dex 的发布状态和它的[许可证](https://docs.superdurable.io/zh-Hans/intro/limits.md#license)。 ## 下一步 - [限制](https://docs.superdurable.io/zh-Hans/intro/limits.md)：容量、可能重复的请求、发布状态和许可证。