在本站中

本站的框架开源：yuxuetr/rustineverything。它没有依赖 tokio-metrics，也没有打开 tokio_unstable。这一部分不是读现成的用法，而是把前面几部分的工具拿来量本站自己：在一个只留在本地、不合并的分支上加上 monitor，跑压测，记下数字。

1. 在本站中实测：按路径分三个 TaskMonitor 的 axum 中间件、包住搜索增量重建的 monitor、只用稳定字段的 RuntimeMonitor。结果：重建几乎全部时间都在两次 poll 里，最长一次至少几百毫秒，远超 10ms 的判定线；但同时段 SSR 请求的排队和延迟看不出变化，原因是 dioxus 把页面渲染放在自己的线程池里。papers 流水线的预期大体成立，但「唯一的同步 IO」那条前提不对：解析 arXiv 全文是一段几十毫秒的同步计算。最后核实打开 tokio_unstable 的三项代价，包括 dx 怎么把 rustflags 分给服务器和 wasm 两次构建。

flowchart TB
  q1["搜索重建：最长的 poll 多长"] --> r1["两次慢 poll，占 98.5% 以上"]
  q2["重建时 SSR 被拖慢了吗"] --> r2["看不出：渲染不在主运行时上"]
  q3["papers：时间花在哪"] --> r3["几乎全是空闲，解析全文是例外"]
  q4["运行时：只用稳定字段"] --> r4["busy 与 park 次数看得出卡住的 worker"]
  r1 --> d["判定：现在不需要 spawn_blocking"]
  r2 --> d
  d --> re["重测条件：文档数或 elapsed_ms 超线"]
  q5["打开 tokio_unstable 要付什么"] --> r5["全量重编、dx 按 section 分发、无 semver"]

读之前最好先读过 包装 waker（嵌套的 Instrumented 量到的排队是什么）和 Worker 差分与 poll 时间直方图（计数为什么滞后），本部分的几个结论都要用到这两页。