[architecture] 评估 Agent Network 性能边界：节点数、任务量、历史记录与 Dashboard 卡顿阈值

[s2agi]

背景

随着 Agent Network 从 v0.10.x 开始进入多 server / 多 runtime / Dashboard 可视化阶段，需要明确当前架构的性能边界：能稳定支持多少节点、多少任务、多少历史记录、多少 SSE 连接，以及 Dashboard 在什么数据规模下会卡顿。

当前系统已经有：

• commhub-server SQLite schema：sessions / tasks / inbox / task_events / agent_telemetry 等表持续增长
• SSE push：按 network + alias 推送状态 / 消息 / telemetry
• Dashboard：Servers / Topology / Tasks / Agents 等视图会聚合大量节点和历史数据
• agent-node：多 runtime 心跳、process telemetry、host telemetry、后续 token usage telemetry

需要从架构层面给出容量上限、瓶颈定位和扩容路线，而不是等用户真实卡住后再补。

目标

产出一份 architecture performance boundary report，回答：

1. 当前 SQLite + Bun server 单机 hub 能支持多少 agent 节点？
2. 能同时承载多少 SSE client / agent connection？
3. tasks / inbox / task_events / agent_telemetry 到多少记录量后查询明显变慢？
4. Dashboard 在多少 nodes / tasks / telemetry points 下渲染卡顿？
5. 哪些 endpoint 最可能成为瓶颈？例如 /api/status、/api/servers、/api/server/:host/health、/api/messages、Topology 数据源。
6. 哪些表需要 index / retention / pagination / aggregation table？
7. 单机 SQLite 到什么量级必须切 PostgreSQL 或分片 / 多 hub？

Scope

Server-side benchmark

• SQLite 表增长测试：sessions / tasks / inbox / task_events / agent_telemetry
• API latency p50 / p95 / p99：
  • GET /api/status
  • GET /api/servers
  • GET /api/server/:host/health
  • GET /api/server/:host/agents
  • GET /api/messages
  • MCP send_task / report_status / get_inbox
• SSE connection scale：100 / 500 / 1000 agent connections 的内存和推送延迟
• write load：agent heartbeat、task events、telemetry 写入频率

Dashboard benchmark

• Servers 面板：server 数 / agent 数增长后的渲染耗时
• Topology 视图：node / edge 数增长后的 FPS / layout 耗时
• Tasks / messages 列表：记录量增长后的加载和滚动性能
• React render flamegraph 或简单 browser performance trace

Data growth / retention

• agent_telemetry 24h / 7d / 30d 记录量估算
• task_events 是否需要 retention / compaction
• 历史 telemetry 是否应做 hourly/daily rollup
• Dashboard 是否应默认只拉 windowed data，而不是 full table snapshot

Deliverables

1. docs/architecture/performance-boundaries.md
2. Docker benchmark suite：tests/perf-architecture-boundary/
3. benchmark report：docs/tests/report-performance-boundaries.md
4. 建议路线：
   • P0：必须立即加的 index / pagination / retention
   • P1：Dashboard virtualization / query windowing
   • P2：PostgreSQL adapter / multi-hub / aggregation table

Suggested test matrix

Scale	Agents	Tasks	Task events	Telemetry rows	SSE clients	Goal
S	50	1k	10k	10k	50	当前小团队 baseline
M	200	10k	100k	100k	200	社区中等部署
L	1k	100k	1M	1M	1k	单 hub 上限探索
XL	5k	500k	5M	5M	5k	证明需要新架构 / PostgreSQL

Non-goals

• 不在本 issue 直接重构数据库。
• 不直接引入 PostgreSQL / Redis / queue。
• 不做生产压测，不碰任何生产 hub。
• 不用真实 LLM 调用；所有 agent / task / telemetry 都用 synthetic data。

验收标准

• 能明确给出当前架构推荐安全上限，例如 “SQLite 单 hub 建议 ≤ X agents / Y tasks / Z telemetry rows”。
• 能指出第一个瓶颈在 server query、SSE、DB write、Dashboard render 还是网络 payload。
• 每个结论有 benchmark 数据支撑，不只主观判断。
• 给出分阶段优化建议，能被拆成后续 implementation issues。

Author-Agent: 通信牛
Helpers: Vincent (architecture boundary request)