性能
查看 Markdown本页给出单个 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 结果目录里，复现结果说明怎样重跑其中一次。
峰值吞吐
| 操作 | 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 解释其中的取舍。
- 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 节点服务。限制介绍这个上限、故障转移和升级。
运行成本
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 在保留期之后被删除，所以存储量取决于这段时间内的 run 数。
复现结果
benchmark/aws 里的脚本可以在你自己的 AWS 账号上重跑一个已记录的测试点。你需要：
- AWS CLI v2 和
openssl，以及一个能管理 EC2、S3 和 IAM 的 profile； - 该 Region 中的一个 EC2 密钥对；
dexbench和dex-server-zd的 Linux arm64 构建，在 Ubuntu 24.04 arm64 上构建，与主机一致。
在同一个可用区里启动共享资源、一台 server 和一台负载主机：
export DEXBENCH_RUN_ID=<run id> DEXBENCH_AWS_PROFILE=<profile> DEXBENCH_AWS_REGION=us-west-2
export DEXBENCH_AZ=us-west-2b DEXBENCH_KEY_NAME=<key pair>
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 数，就会重跑所有测试点：
benchmark/aws/reproduce.sh benchmark/results/<run> sequential-steps 512
完成后删除所有资源。这些实例也会在两个半小时后自行关机。
benchmark/aws/teardown.sh
发布状态和许可证
下一步
- 限制：容量、可能重复的请求、发布状态和许可证。