性能与容量

本页回答两个问题:能跑多快(本地可复现实测)与能扛多少(按契约限制做容量估算)。所有性能数字都标注环境口径;不同机器、TLS、公网 RTT、release 构建都会改变结果,请把本页当作基线而不是承诺。

实测口径(不要外推成公网 SLA)

环境:单机 Windows、服务端与客户端同机、loopback、debug 构建、独立服务端实例。

未覆盖:公网 RTT / TLS / NAT、release 构建、多区域、PostgreSQL 模式、真实移动端渲染、厂商推送。

“客户端到客户端”时延 = 发送端调用前 performance.now() → 接收端 SDK MESSAGES 事件(应用可渲染时刻),不使用服务端内部计时。

实测基线(2026-10-27)​

场景样本p50p95判定
单聊文本(发一条等一条)3001.01ms1.61msp95 ≤50ms 达标
单聊文本(20 msg/s 持续)4001.35ms2.01ms达标
群聊文本(2 人群,paced)3001.04ms1.62msp95 ≤80ms 达标
群聊文本(20 msg/s 持续)4001.32ms2.04ms达标
图片消息投递1001.12ms1.83ms达标
文件消息投递1001.06ms1.73ms达标
断线重连 → 离线补收完成3 轮 ×100 条516ms645msp95 ≤1500ms;0 丢失 / 0 重复
50,000 条单会话历史首屏——71–114msp95 <300ms 达标
1,000 会话列表——141.6msp95 <300ms 达标
1,000 行列表滚动——60fps;>200ms long task = 0达标
20 分钟长跑(20 msg/s ×20 连接)23,567 条—0 失败 / 0 丢失功能通过;RSS 原始斜率 53.2MB/h 超阈值(已记录)

长跑的 RSS 斜率来自 debug 构建 + append-only journal 的分配行为,归一化到数据量后为负值;release 构建与 PostgreSQL 模式的常驻内存未测,生产容量必须自行压测。

容量估算输入​

参数契约值用途
单用户发送频率120 条/分钟峰值 = 在线用户数 × 单用户峰值(再乘突发系数)
输入状态频率60 条/分钟输入态是高频小帧,需客户端节流(建议 500ms 防抖)
单聊/群聊离线消息每会话 500 条决定重连补收的数据量与首屏时间
历史分页默认 20 / 最大 100决定单次查询成本
群成员上限普通群 3000 / 超级群 100000群发扇出基数
聊天室在线5000单房间广播扇出上限
消息体5120 字节带宽与存储估算
在线状态批量/订阅100 / 500订阅型业务的容量约束

估算公式(可直接套用)​

Text
峰值入站消息/s   = 在线用户数 × 单用户峰值发送率 / 60 × 突发系数(1.5~3)
峰值广播扇出/s   = 群/聊天室消息/s × 平均成员数(聊天室按在线数)
重连补收峰值     = 同时断线用户数 × min(离线消息数, 500) × 消息大小
存储日增量       ≈ 日活 × 人均发送条数 × 平均消息体(含索引/审计副本)
连接内存估算     = 在线连接数 × 每连接会话开销(需实测,不能只看消息吞吐)
先压“连接数”再压“消息速率”

很多事故不是吞吐不够,而是连接态内存/文件描述符耗尽。压测至少覆盖:在线连接阶梯(1k/5k/10k)、每连接 1 msg/s、断线重连风暴(同时断 10% 连接)、群发扇出。

优化清单(按收益排序)​

  1. 客户端:输入状态防抖、列表虚拟化、历史分页 20–50 条、图片懒加载;避免每次事件全量重渲染。
  2. 发送端:本地节流到 120 条/分钟以下;失败重试复用 clientMsgId,避免重复消息放大。
  3. 群发:优先超级群/频道;控制单群扇出,必要时业务侧分批。
  4. 聊天室:弹幕折叠低优先级类型(配合 chatroom.message.priority.set),在线人数 1–5 秒刷新一次。
  5. 服务端:release 构建、按 CPU/内存压测;会话持久化与 journal 的 IO 需单独验证。
  6. 监控:记录 p95/p99、重连率、离线队列深度、回调失败率;不要只看平均值。

相关页面​