实时消息目标容量压测报告
真实任务与实时消息链路在目标并发容量下的性能和稳定性验证结果
本文记录真实任务和实时消息链路在目标容量下的压力测试结果，重点验证多会话同时运行时的消息速度、顺序、完整性和服务稳定性。
真实任务测试于 2026 年 7 月 14 日完成，最新流消息容量测试于 2026 年 7 月 15 日完成。本文数据仅代表本次测试环境、测试配置和测试范围，不用于直接推断其他硬件或部署规模下的性能。
测试结论
本次目标容量验证通过：
- 20 个真实任务同时执行时，20 个任务全部完成，没有失败。
- 一次提交 30 个真实任务时，20 个任务同时执行，其余任务正常排队，最终 30 个任务全部完成。
- 2、20、50 和 100 个会话同时发送流消息时，消息均完整送达，没有乱序、缺失、重复或跨会话混淆。
- 实时消息与历史回放的内容和顺序一致。
- 20 并发下，用户看到第一条有效回复的速度比改动前旧链路更快。
- 最新流压力下，Backend CPU 最高为 85.9%，各核心服务均未重启或发生内存不足退出。
测试范围
本次测试包含四类场景：
| 场景 | 测试内容 | 主要观察项 |
|---|---|---|
| 真实任务并发 | 同时提交 20 个任务 | 任务完成率、用户看到回复的速度、消息顺序 |
| 排队与调度 | 一次提交 30 个任务，执行并发上限为 20 | 排队是否正常、任务是否全部完成 |
| 流消息压力 | 2/20/50/100 个会话，每个会话发送 200 条事件 | 消息吞吐、实时延迟、重复和乱序情况 |
| 历史回放 | 任务完成后重新读取消息历史 | 实时内容与历史内容是否一致 |
测试环境的主要容量配置：
| 配置项 | 配置值 |
|---|---|
| 服务器 CPU | 32 核 |
| 服务器内存 | 约 64 GiB |
| 同时执行任务上限 | 20 |
| Executor 容器总量上限 | 30 |
| 单个 Executor CPU 上限 | 4 核 |
| 单个 Executor 内存上限 | 4 GiB |
真实任务并发结果
20 个任务同时执行
连续进行了两轮 20 并发测试，两轮均全部成功。下表展示第二轮结果：
| 指标 | P50 | P95 | 说明 |
|---|---|---|---|
| 任务提交耗时 | 1.22 秒 | 1.26 秒 | 从发起请求到任务进入系统 |
| 第一条运行事件 | 4.42 秒 | 10.44 秒 | 前端开始收到任务运行状态 |
| 第一条流消息 | 28.57 秒 | 37.56 秒 | 开始收到模型流式消息 |
| 第一条用户可见回复 | 33.87 秒 | 40.16 秒 | 用户界面出现有效回答内容 |
| 任务完成 | 38.17 秒 | 41.52 秒 | 任务进入完成状态 |
| 历史消息读取 | 0.60 秒 | 0.63 秒 | 任务完成后读取完整消息历史 |
P50 表示一半请求的耗时不超过该数值；P95 表示 95% 的请求耗时不超过该数值。
20 个任务全部使用带序号的实时消息链路，未切换到旧的回调链路。
与之前基线对比
以下对比使用相同的 20 并发测试方式。改动前的 20 个任务均通过 Executor Manager 转发实时消息；当前版本的 20 个任务均使用带序号的实时消息链路。
| 指标 | 改动前旧链路 | 当前链路 | 变化 |
|---|---|---|---|
| 第一条用户可见回复 P50 | 39.78 秒 | 33.87 秒 | 快 14.9% |
| 第一条用户可见回复 P95 | 43.61 秒 | 40.16 秒 | 快 7.9% |
| 任务完成 P50 | 45.64 秒 | 38.17 秒 | 快 16.4% |
| 任务完成 P95 | 48.83 秒 | 41.52 秒 | 快 15.0% |
在本次测试中，当前链路的第一条用户可见回复 P50 缩短约 5.91 秒，任务完成 P50 缩短约 7.47 秒。
30 个任务提交与排队
系统执行并发上限为 20。一次提交 30 个真实任务时，系统先执行 20 个任务，其余 10 个任务正常等待；前一批任务完成后，等待任务继续执行。
| 检查项 | 结果 |
|---|---|
| 成功提交 | 30/30 |
| 最终完成 | 30/30 |
| 任务失败 | 0 |
| 消息校验错误 | 0 |
| 消息重复 | 0 |
| 实时消息链路 | 30/30 使用带序号链路 |
这组测试说明达到并发上限后，新增任务会正常排队，不会因为短时间集中提交而丢失。
流消息压力结果
该测试不等待模型生成内容，而是直接模拟 Executor 持续发送流事件，用于单独观察消息链路的处理能力。
| 并发会话 | 每个会话事件数 | 总事件数 | 吞吐量 | 实时延迟 P50 | 实时延迟 P95 | Backend CPU 平均 / 峰值 |
|---|---|---|---|---|---|---|
| 2 | 200 | 400 | 171.52 条/秒 | 10.7 ms | 16.9 ms | 短时样本，仅供参考 |
| 20 | 200 | 4,000 | 110.94 条/秒 | 85.9 ms | 539.8 ms | 41.6% / 58.7% |
| 50 | 200 | 10,000 | 101.58 条/秒 | 315.8 ms | 1.35 秒 | 45.5% / 64.2% |
| 100 | 200 | 20,000 | 93.18 条/秒 | 676.6 ms | 3.05 秒 | 46.2% / 85.9% |
四组测试的正确性结果一致：
| 并发会话 | 消息缺失 | 消息重复 | 顺序错误 | 跨会话混淆 | 历史内容不一致 |
|---|---|---|---|---|---|
| 2 | 0 | 0 | 0 | 0 | 0 |
| 20 | 0 | 0 | 0 | 0 | 0 |
| 50 | 0 | 0 | 0 | 0 | 0 |
| 100 | 0 | 0 | 0 | 0 | 0 |
100 会话用于验证消息链路在高输入压力下的稳定性，不会创建 100 个真实 Executor 容器，也不包含模型生成和工具执行耗时。真实任务的目标执行并发仍为 20。
实时消息与历史回放
每个真实任务完成后，测试程序会重新读取该任务的历史消息，并与实时收到的消息逐项对比。
对比范围包括：
- 任务和会话标识是否一致。
- 消息序号是否连续且保持递增。
- 消息类型和数量是否一致。
- 用户最终看到的回答内容是否一致。
- 是否存在重复、缺失或交叉到其他会话的消息。
本次所有真实任务和模拟流事件均通过校验。最新流压力中，2/20/50/100 个会话的 REST 历史和 SSE 重放均与实时内容一致。多会话同时运行时，没有发现消息串到其他会话，也没有出现实时内容与历史内容不一致。
服务资源情况
真实任务端到端资源峰值
| 服务或资源 | 测试期间峰值 |
|---|---|
| Backend CPU | 约 1.82 核 |
| Backend 内存 | 约 312 MiB |
| Executor Manager CPU | 约 1.04 核 |
| Executor Manager 内存 | 约 126 MiB |
| PostgreSQL CPU | 约 0.70 核 |
| PostgreSQL 内存 | 约 716 MiB |
| 主机一分钟平均负载 | 9.83 / 32 核 |
| 主机最低可用内存 | 约 45 GiB |
测试期间同时运行的任务数最多为 20，符合配置。Executor 容器池最多保留 30 个容器，符合容器总量上限。
最新流消息资源峰值
最新流消息测试直接模拟 Executor 发送事件，用于观察 Backend 消息入口在不同会话数量下的资源变化。Docker CPU 100% 约等于使用 1 个 CPU 核心。
最高压力为 100 个会话、共 20,000 条事件，Backend CPU 峰值为 85.9%。测试期间 Backend、Executor Manager、Frontend 和 PostgreSQL 均保持正常运行，没有重启或发生内存不足退出。
稳定性检查
| 检查项 | 结果 |
|---|---|
| Backend 重启次数 | 0 |
| Executor Manager 重启次数 | 0 |
| Frontend 重启次数 | 0 |
| 任务容量错误 | 0 |
| 内存不足退出 | 0 |
| 最新流压力消息错误 | 0 |
| 压测结束后遗留活动任务 | 0 |
| 压测结束后遗留 Executor 容器 | 0 |
验收结论
在本次测试环境和目标容量范围内，实时消息链路满足以下要求：
- 20 个任务可以同时稳定执行，超过执行上限的任务能够正常排队。
- 最高 100 个模拟会话并发发送流消息时，实时消息按正确顺序到达，没有缺失、重复或跨会话混淆。
- 实时消息与任务完成后的历史回放保持一致。
- 用户看到有效回复的速度比改动前旧链路更快。
- 最新流压力下 Backend CPU 峰值为 85.9%，测试期间没有发生服务重启或内存不足退出。
因此，本次实时消息链路的目标容量验证结果为 通过。