为何不让agent端也走ws推送，把推送和历史的写入分开，do入站请求才消耗请求次数，do内部ws消息大约是20次消息：1次请求，理论上一天的额度，3秒推送的频率可以支持60台左右，以此类推。历史数据可以从do里面X分钟写入一次到d1，这样的话虽然历史数据受D1限制服务器数量还是原来的，但是前端推送频率可以接近实时。
@asphyixa #31 发布于2026/8/13 12:06:51 为何不让agent端也走ws推送，把推送和历史的写入分开，do入站请求才消耗请求次数，do内部ws消息大约是20次消息：1次请求，理论上一天的额度，3秒推送的频率可以支持60台左右，以此类推。历史数据可以从do里面X分钟写入一次到d1，这样的话虽然历史数据受D1限制服务器数量还是原来的，但是前端推送频率可以接近实时。 前几天刚和群友讨论过，还没尝试。但x分钟写入也是消耗一样的D1写入行。 目前瓶颈是Workers请求数和D1写入行数，接下来会往这方面优化
@asphyixa #31 发布于2026/8/13 12:06:51 为何不让agent端也走ws推送，把推送和历史的写入分开，do入站请求才消耗请求次数，do内部ws消息大约是20次消息：1次请求，理论上一天的额度，3秒推送的频率可以支持60台左右，以此类推。历史数据可以从do里面X分钟写入一次到d1，这样的话虽然历史数据受D1限制服务器数量还是原来的，但是前端推送频率可以接近实时。 昨天改了，然后额度崩了。。 您的 DO 使用了 WebSocket Hibernation API，请求类型几乎全是 hibernation（242,473 次）。这是每次 WebSocket 消息到达时将 DO 从休眠中唤醒的次数，不是 WebSocket 消息本身。每次唤醒被计为 1 次请求（1:1），不走 1:20 比例。 1:20 的比例只适用于 WebSocket 消息本身（outbound 621,176 条 → 计费 31,059 次），不适用于 hibernation 唤醒。 只要指标是 Agent -> DO，每条新指标进入 DO 都是一次 incoming event；DO 休眠时就会被唤醒。Outbound WebSocket message 只能用于 DO -> 前端/Agent，不能承载 Agent 主动上报的新数据。 能做的只有这几类取舍： 1. 保持 Hibernation - 优点：几乎不产生 idle duration。 - 缺点：Agent 每次发消息都会唤醒 DO。 - 适合低频、批量上报。 2. 不用 Hibernation，改成标准 WebSocket - DO 不休眠，所以不存在“每 3 秒唤醒”。 - 但 DO 会被 WebSocket 长连接钉在内存里，持续产生 duration/GB-s。 - incoming 消息仍然是进入 DO 的事件，不会变成 outbound 免费消息。 - 这通常不是免费额度场景的好选择。 3. 真正降低成本的改法 - Agent 仍每 3 秒本地采样，但不要每 3 秒发给 DO。 - 改成每 30s/60s 发一次 batch：一帧里带 samples: [...]。 - DO 只被唤醒一次，然后一次性把这批样本 outbound 推给前端。 - 这样可以把 20 次唤醒/分钟/服务器 降到 1-2 次唤醒/分钟/服务器。 所以可行方案不是“唤醒一次后改 outbound”，而是“把多次 Agent inbound 合并成一次 inbound，再由 DO outbound 广播”。当前项目已经有 batchUpdate 协议基础，比较适合往这个方向改。 白折腾了，上报不支持走1/20比例的扣费凡是
@asphyixa #37 agent 每3秒上报就不能改成Outbound WebSocket 消息消息吗，而不是每次了Hibernation 唤醒 • Searching the web • Searched the web for site:developers.cloudflare.com/durable-objects/platform/pricing Durable Objects WebSocket outgoing messages incoming messages pricing ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── • 不能。Outbound WebSocket message 的方向必须是 DO 发出去： DO -> Agent DO -> 前端 但 Agent 上报指标的方向天然是： Agent -> DO 这在 DO 看来永远是 incoming message。只要这条消息里带 CPU/内存/流量数据，DO 就必须收到并执行 webSocketMessage()，因此 hibernated DO 会被唤醒。不能通过改 Agent 把“Agent 发给 DO 的指标”变成“DO outbound 免费消息”。 我看了你新增的 cfsm-agent，它的 WSS 方式本身不是错的： - cfsm-agent/internal/cfprobe/report_transport.go 会把 https://.../update 转成 wss://.../update - 用 GET + Upgrade 建立 WebSocket - 建连后复用同一条连接 WriteText(...) 发业务 JSON - Worker 侧 MetricsBroadcaster 用的是 state.acceptWebSocket(server)，后续走 webSocketMessage() 所以它已经是 DO WebSocket incoming message，不是每 3 秒重新 HTTP 请求，也不是错误走法。你看到的每 3 秒 hibernation 唤醒，正是这个模式的正常结果。 能改的是策略： 现在： Agent 每 3 秒发一次 -> DO 每 3 秒醒一次 建议： Agent 本地每 3 秒采样 Agent 每 30/60 秒批量发一次 samples DO 每 30/60 秒醒一次 DO 再 outbound 推给前端 或者更简单一点：服务端 ack 不再返回 nextWssReportAfterMs = 3000，而是始终返回 report_interval，让 Agent 保持 WSS 长连接但低频上报。这是最直接降 hibernation wakeup 的改法。 就是说不能走1/20的方式，搞不懂
为何不让agent端也走ws推送，把推送和历史的写入分开，do入站请求才消耗请求次数，do内部ws消息大约是20次消息：1次请求，理论上一天的额度，3秒推送的频率可以支持60台左右，以此类推。历史数据可以从do里面X分钟写入一次到d1，这样的话虽然历史数据受D1限制服务器数量还是原来的，但是前端推送频率可以接近实时。
前几天刚和群友讨论过，还没尝试。但x分钟写入也是消耗一样的D1写入行。
目前瓶颈是Workers请求数和D1写入行数，接下来会往这方面优化
@huilang #32 agent端走ws推送就没Workers请求数的消耗了 ，D1就还是保持原来的频率就行了。
@asphyixa #33
就按这个逻辑，可以省下大把Workers额度。
目前60台，其实也很充足了，只是延迟较大，但不排除用户有多项目
好用好用 正好想改主题 顶楼主
昨天改了，然后额度崩了。。
白折腾了，上报不支持走1/20比例的扣费凡是
@huilang #36
@asphyixa #37
@asphyixa #37
就是说不能走1/20的方式，搞不懂
@huilang #38 你前面的回复不都是答案吗，这个推送频率用不到休眠，免费额度足够一个do实例7x24小时不间断。