問題不是「資源用得多」,而是「哪個函式在用」
Workers 的疑難排解長期卡在一個地方:log 和聚合指標能告訴你出事了,卻說不出是哪段程式碼在吃資源。Cloudflare 在 2026 年 10 月 9 日發布了 Workers 和 Durable Objects 的按需 CPU 與記憶體分析功能,你可以從 Workers Observability 頁面對一個正在運行的 Worker 發起分析請求,用互動式 flamegraph 查看結果,並下載 profile 檔案做進一步分析。重點在於:這是對生產環境做 profile,而不是本地模擬。
操作路徑有兩條。CLI 方式需要先安裝 cf 套件;dashboard 則是從 Build → Compute → Workers & Pages 選定 Worker,進入 Observability 分頁,在下拉選單選「Flamegraph」。你可以選擇要分析的版本和分析時長,然後點 Capture Profile。要注意的是,分析不會為你啟動新的 isolate——目的是觀察真實的生產執行,所以流量太少的版本很難成功取樣。
flamegraph 怎麼看
每個矩形代表一個函式呼叫,寬度對應該函式佔用的 CPU 時間或記憶體量。Cloudflare 的建議很實在:多取幾次 profile,找最寬的方塊;如果視覺化不夠直觀,就切到 table view 按 Samples 排序。
他們內部有一個很好的示範。R2 binding 的 Worker 流量極大,團隊取了 50 秒的 CPU trace。最寬的幾個函式(decryptBlock、fillResponse)都是合理開銷,但 table view 揪出了 genericR2JsonReplacer:它佔了超過 5% 的 CPU 時間,原因是它被 JSON.stringify 呼叫後,自己又遞迴走了一遍 JSON 樹——五層深的值被處理五次。修掉重複工作後,這個函式快了 2.7 倍。另一個發現是 metrics 被重複呼叫,單次呼叫就佔 1% 的 CPU,把第一次結果存進變數就省下一筆。
記憶體問題的例子更值得看
Cloudflare 內部有一個 Worker,P999 記憶體落在 133 MB,逼近 128 MB 上限,經常被「Exceeded Memory」錯誤驅逐。指標指出是記憶體問題,但無法解釋是哪段程式碼造成的。
團隊對生產環境的 Worker 取了 heap profile,用 pprof 開啟,發現約 66.7% 的配置來自 Prometheus 程式碼——一段以為已經停用、實際上只被部分停用的程式碼。它還在對大量程式碼路徑做 instrumentation,收集的資料從未離開 Worker,記憶體成本卻照付。整個移除後,P50 從 70 MB 降到 54 MB,P999 從 133 MB 降到 118 MB,上限下留出了約 10 MB 的餘裕。
這個案例的教訓對任何平台都成立:「以為已經關掉的功能」是最不會被懷疑的嫌疑人,只有 profile 能證明它還在花錢。
在邊緣做 profile 的工程代價
Workers 之前只能透過 Chrome DevTools 做本地分析。要對生產環境取樣,得先回答幾個問題:要分析哪個版本?它最近在哪個資料中心跑過?isolate 還載入著嗎?isolate 是否屬於發起請求的帳號?對 Durable Objects 還要加上:那個具名 actor 的 live primary 現在在哪?Cloudflare 並未在文中完整說明這些問題如何逐一解析,但可以確認的是,分析請求的 URL 中明確指定了 script name 和 version,而且你也可以自己發請求——或讓你的 coding agent 代勞。
Runtime 端的設計也值得留意:分析期間不能鎖死 isolate,否則就看不到真實執行。所以 CPU profiling 的流程是取鎖、啟動 V8 profiler(每毫秒取樣一次)、釋放鎖讓請求繼續跑、等待時長後重新取鎖停止,最後在關鍵區段之外序列化結果。Durable Objects 因為有狀態且有名字,反而更簡單——按名稱指定物件,runtime 會把請求路由到持有該 actor 的機器。
目前的限制
這是手動觸發的分析,可能錯過 Worker 出問題的時間窗;記憶體分析也只涵蓋取樣期間的配置,啟動階段的配置看不到。Cloudflare 表示正在開發 continuous profiling,讓取樣自動進行。另外,TypeScript 專案記得啟用 source maps,否則 flamegraph 上會是一堆難以閱讀的混淆函式名。
實用的下一步:挑一個你有懷疑但缺證據的 Worker,在有流量的版本上取一次 CPU 和一次記憶體 profile,先看 table view。這類把可觀測性能力下放到一般開發者的做法,其實延續了 Cloudflare 這一年把原本只給少數人的工具變成標準配備的路線(我之前在另一篇文章也提過類似觀察)。不過在 continuous profiling 落地之前,偶發性的異常仍然要靠運氣才取得到樣本。