性能基准测试
Supabase Realtime 的可扩展性基准测试
本指南探讨了 Realtime 功能的可扩展性：广播(Broadcast)、在线状态(Presence)和 Postgres 变更监听(Postgres Changes)。
测试方法
- 基准测试使用开源负载测试工具 k6，针对部署在 AWS 上的 Realtime 集群进行
- 集群配置采用 2-6 个节点，测试了单区域和多区域部署方案，所有节点均连接到同一个 Supabase 项目
- 负载生成器(k6服务器)部署在 AWS 上，以最小化网络延迟对结果的影响
- 测试从一开始就施加全负载，不进行预热运行
收集的指标包括：消息吞吐量、延迟百分位、CPU 和内存利用率以及连接成功率。请注意，生产环境中的性能可能会因网络条件、硬件规格和具体使用模式等因素而有所不同。
工作负载
设计的工作负载旨在展示 Supabase Realtime 的吞吐量和可扩展性。这些基准测试聚焦于核心功能和常见使用模式，测试结果包含以下工作负载：
- 广播性能
- 有效载荷大小对广播的影响
- 大规模广播
- 认证与新连接速率
- 数据库事件
测试结果
广播：使用 WebSocket
该工作负载评估系统处理多个并发 WebSocket 连接并通过 WebSocket 发送广播消息的能力。测试中的每个虚拟用户(VU)：
- 建立并维持一个 WebSocket 连接
- 加入两个不同的频道：
- 回声频道（每个频道1个用户）用于直接消息反射
- 广播频道（每个频道6个用户）用于群组通信
- 通过每分钟向每个加入的频道发送2条消息来生成流量，持续10分钟
| 指标 | 值 |
|---|---|
| 并发用户数 | 32,000 |
| 总频道加入数 | 64,000 |
| 消息吞吐量 | 224,000 条/秒 |
| 中位延迟 | 6 毫秒 |
| 延迟(p95) | 28 毫秒 |
| 延迟(p99) | 213 毫秒 |
| 接收数据量 | 6.4 MB/秒 (总计7.9 GB) |
| 发送数据量 | 23 KB/秒 (总计28 MB) |
| 新连接速率 | 320 连接/秒 |
| 频道加入速率 | 640 加入/秒 |
广播：使用数据库
该工作负载评估系统通过 realtime.broadcast_changes 函数从数据库发送广播消息的能力。测试中的每个虚拟用户(VU)：
- 建立并维护一个 WebSocket 连接
- 加入一个独立频道：
- 单一频道（每个频道100名用户）用于群组通信
- 数据库设置了触发器，在每次插入时执行
realtime.broadcast_changes - 数据库每秒触发10,000次插入
| 指标 | 数值 |
|---|---|
| 并发用户数 | 80,000 |
| 总频道加入数 | 160,000 |
| 消息吞吐量 | 10,000 条/秒 |
| 中位延迟 | 46 毫秒 |
| 延迟(p95) | 132 毫秒 |
| 延迟(p99) | 159 毫秒 |
| 接收数据量 | 1.7 MB/秒 (总计42 GB) |
| 发送数据量 | 0.4 MB/秒 (总计4 GB) |
| 新建连接速率 | 2000 连接/秒 |
| 频道加入速率 | 4000 加入/秒 |
广播：负载大小的影响
该工作负载测试系统在不同消息负载大小下的性能，以了解数据量如何影响吞吐量和延迟。每个虚拟用户(VU)遵循与广播测试相同的连接模式，但使用不同大小的消息：
- 建立并维护一个 WebSocket 连接
- 加入两个独立频道：
- 回声频道（每个频道1名用户）用于直接消息反射
- 广播频道（每个频道6名用户）用于群组通信
- 发送1KB、10KB和50KB大小的负载消息
- 通过向每个加入的频道每秒发送2条消息来生成流量，持续5分钟
1KB负载
10KB 负载
50KB 负载
| 指标 | 1KB负载 | 10KB负载 | 50KB负载 | 50KB负载(降低负载) |
|---|---|---|---|---|
| 并发用户数 | 4,000 | 4,000 | 4,000 | 2,000 |
| 消息吞吐量 | 28,000 条/秒 | 28,000 条/秒 | 28,000 条/秒 | 14,000 条/秒 |
| 中位延迟 | 13 毫秒 | 16 毫秒 | 27 毫秒 | 19 毫秒 |
| 延迟(p95) | 36 毫秒 | 42 毫秒 | 81 毫秒 | 39 毫秒 |
| 延迟(p99) | 85 毫秒 | 93 毫秒 | 146 毫秒 | 82 毫秒 |
| 接收数据量 | 31.2 MB/s(10.4 GB) | 268 MB/s(72 GB) | 1284 MB/s(348 GB) | 644 MB/s(176 GB) |
| 发送数据量 | 9.2 MB/s(3.1 GB) | 76 MB/s(20.8 GB) | 384 MB/s(104 GB) | 192 MB/s(52 GB) |
注意：最后一列展示了50KB负载测试在降低负载(2,000用户)下的结果，展示了系统在不同并发级别下处理较大负载时的性能表现。
广播：可扩展性场景
此工作负载展示了 Realtime 处理大规模并发用户和广播频道的能力。测试模拟了每个用户参与群组通信并定期广播消息的场景。每个虚拟用户(VU)：
- 建立并维护一个 WebSocket 连接（30-120分钟）
- 加入2个广播频道
- 每分钟向每个加入的频道发送1条消息
- 每条消息广播给100个其他用户
| 指标 | 值 |
|---|---|
| 并发用户数 | 250,000 |
| 总频道加入数 | 500,000 |
| 每频道用户数 | 100 |
| 消息吞吐量 | >800,000 条/秒 |
| 中位数延迟 | 58 毫秒 |
| 延迟(p95) | 279 毫秒 |
| 延迟(p99) | 508 毫秒 |
| 接收数据量 | 68 MB/s (600 GB) |
| 发送数据量 | 0.64 MB/s (5.7 GB) |
实时认证
本工作负载展示了Realtime在启用通道认证行级安全(RLS)的情况下，处理每秒大量新连接和通道加入的能力。测试模拟了大量用户连接到实时服务并参与受认证保护的通信场景。每个虚拟用户(VU)：
- 建立并维持WebSocket连接（2.5分钟）
- 加入2个广播频道
- 每分钟向每个加入的频道发送1条消息
- 每条消息广播给100个其他用户
| 指标 | 值 |
|---|---|
| 并发用户数 | 50,000 |
| 总频道加入数 | 100,000 |
| 每频道用户数 | 100 |
| 消息吞吐量 | >150,000 条/秒 |
| 新连接速率 | 500 连接/秒 |
| 频道加入速率 | 1000 加入/秒 |
| 中位延迟 | 19 毫秒 |
| 延迟(p95) | 49 毫秒 |
| 延迟(p99) | 96 毫秒 |
Postgres 变更
实时系统通常需要预先考虑扩展动态问题。对于 Postgres 变更 功能，每个变更事件都需要检查订阅用户是否有访问权限。例如，如果有100个用户订阅了一个表，当您执行一次插入操作时，将触发100次"读取"：每个用户各一次。
这可能导致数据库瓶颈，限制消息吞吐量。如果数据库无法快速授权变更，变更将被延迟直到超时。
数据库变更在单线程上处理以保持变更顺序。这意味着计算升级对Postgres变更订阅的性能影响不大。您可以通过下方工具估算数据库的预期最大吞吐量。
如果您大规模使用Postgres变更功能，应考虑使用没有RLS（行级安全）和过滤器的独立"公共"表。或者，您可以仅在服务器端使用Realtime，然后通过Realtime广播将变更重新流转给客户端。
输入您的数据库设置以估算实例的最大吞吐量：
Set your expected parameters
Current maximum possible throughput
| Total DB changes /sec | Max messages per client /sec | Max total messages /sec | Latency p95 |
|---|---|---|---|
| 64 | 64 | 32,000 | 238ms |
View raw throughput table
别忘了运行自己的基准测试，确保性能符合您的使用场景需求。
Supabase持续改进Realtime的Postgres变更功能。如果您对使用场景的性能不确定，请通过支持表单联系我们。支持团队可以为每个使用场景提供最佳解决方案建议。