Dashboard 性能优化（2026-07）——前端对接说明

GET /api/v1/ui/dashboard 及相关流量端点在两个控制面（Python / TS Worker）同步做了一轮 P0 性能优化。响应字段形态零变更，前端不需要改解析代码；本文说明三处行为语义的变化与建议，供前端确认轮询与展示逻辑。

变更总览

#	变更	生效面	前端可见影响
1	dashboard 响应短 TTL 缓存（3s）	TS 面新增（Python 面原本就有）	高频轮询可能拿到 ≤3s 前的同一份响应
2	流量默认序列窗口固定为最近 10 小时	两面同步	默认流量图历史深度有了明确上限
3	服务端聚合去重（内部优化）	两面同步	无（纯提速）

TS 面（api.natlan.io）的 GET /ui/dashboard 现在按完整 URL（含全部 query） 缓存 3 秒——与 Python 面既有的 3s Redis TTL 语义一致，两面从此行为对齐。
判断数据实际生成时刻请读响应内的 generated_at 字段（缓存命中时它是缓存体的生成时间，不是本次请求时间）——需要展示「数据更新于 x 秒前」时以它为准，不要用本地请求时间。
不同 query 参数组合是不同缓存键（?range=24h 与默认视图互不影响）。
建议轮询间隔 ≥3s（更快只会拿到同一份缓存）；当前 webui 的轮询节奏无需调整。
缓存体不含任何用户特定字段（identity 只在 /ui/session，不受影响）。

涉及端点（不带 ?range= 参数的默认形态）：

此前默认形态在存档积累变多后会返回整段 60 天历史（数万点）；现在明确为 最近 120 桶 × 5min = 10 小时（升序、有数据的桶才出点，形态不变）。

前端注意：

默认流量图最多 ~120 点——与设计初衷一致，多数页面无感知；
需要更长历史一律用 ?range=6h|24h|7d|30d（定长网格 + 空桶 null + 可选 compare=1 上期对比），该路径不受本次变更影响；
若有页面依赖默认形态拿超过 10 小时的数据（不应有），改用 range 参数。

dashboard 五个聚合块共享一次 node_status / desired-state 读取（原先各块重复拉取，大 JSON 解析 36 份 → 9 份）；
fleet 状态列表查询不再拖回 last_snapshot 等大 JSON 列；
实测（9 节点，beta 面）：冷请求 8.7s → ~1.5s，缓存命中 ~0.3s。

响应字段形态仍零变更，前端无需改代码。三项内容与新增语义：

desired-state KV 缓存（TS 面）：generation 键（内容不可变），Python 面本就有同语义 Redis 缓存——两面对齐。无前端可见影响。
快照摄入预提取小列（两面同步，node_status.bgp_summary / peer_rates）： peering-issues / bgp 会话状态 / /ui/nodes 行富化 / traffic-breakdown 对端速率改读摄入时算好的小 JSON 列（与原算法同形态），不再解析几百 KB 的完整快照；列未填充（节点尚未再上报）自动回退旧路径。 ⚠️ 运维前置：Python 面下次重建容器前，必须先对 dn42_control 库手动执行ALTER TABLE node_status ADD COLUMN bgp_summary jsonb; ALTER TABLE node_status ADD COLUMN peer_rates jsonb;（create_all 不加列；TS 面两库已应用）。
routing 总览块 cron 预计算（TS 面）：dashboard 缺省参数（无 range、 origins_top=100、origins_sort=count）下 routing 块由每分钟的 cron 预计算供给（KV，TTL 3min，cron 停摆自动回退实时计算）。前端注意：该块数据新鲜度上限 ≤60 秒（底层路由采集本就是 ~5min 粒度，无感知）；带任何非缺省参数即回实时路径。

实测（9 节点，beta 面）：3s 缓存命中 ~0.25s；缓存 miss 从 P0 后的 ~1.5s 进一步降到 ~0.6–0.9s。