Cloudflare 帳單管線突然變慢：一把 ClickHouse 互斥鎖引發的效能危機
Cloudflare Blog · 2026-05-14
Cloudflare 工程團隊在 2026 年 5 月公開了一起 ClickHouse 效能事件的完整診斷過程：帳單管線在將 Ready-Analytics 資料表遷移至新的 (namespace, day) 分區方案後，效能持續惡化，I/O、記憶體與查詢指標卻看起來正常。根本原因是查詢規劃器中一把保護 parts list 的互斥鎖導致上百個並發查詢單排等候。
診斷過程
工程師使用 ClickHouse 內建的 trace_log 系統資料表生成火焰圖。以 CPU 模式追蹤時，45% 的時間花在 filterPartsByPartition，表面上看是正常的過濾工作。切換為「Real」模式（捕捉等待中的執行緒）才暴露真正瓶頸：MergeTreeData 互斥鎖上的鎖競爭，執行緒們形成長隊等待。
根本原因
查詢規劃器的流程是：取得 MergeTreeData 的獨占鎖、複製全部 parts 清單、釋放鎖、再過濾出相關 parts。當資料表累積數萬個 parts 且有數百個並發查詢時，這個串行化的複製操作成為系統瓶頸。
三階段修補
| 優化 | 措施 | 效果 |
|---|---|---|
| 1. 共享鎖 | 將獨占鎖改為 std::shared_lock | 立即大幅降低鎖競爭 |
| 2. 向量複製 | 快取唯讀 parts 清單，規劃器僅複製過濾後的子集 | 顯著進一步改善 |
| 3. 二分搜尋 | 對 namespace 分區鍵實作二分搜尋 | 延遲降低 50%；打破查詢時間與 part 數量的線性相關 |
修補後，系統在一年內 parts 數量從 30,000 增長至 160,000 的情況下，效能保持穩定。相關 PR #85535 已合入 ClickHouse 25.11 上游，其他使用者可直接受益。
原始來源：Cloudflare Blog
「空閒」並不空閒：Linux 核心優化導致的 QUIC CUBIC 死亡螺旋
Cloudflare Blog · 2026-05-12
Cloudflare 的 quiche QUIC 實作中存在一個 bug，使 CUBIC 壅塞視窗（cwnd）在發生封包遺失後永遠卡在最小值（2,700 bytes / 2 封包），導致下載在 10 秒視窗內逾時。診斷過程追溯至一個 2017 年 Linux 核心的優化，在移植時遺漏了後續的修正。
漏洞機制
Linux 核心的優化原意是在空閒期間調整 epoch 時機，防止 cwnd 通膨。核心問題在於：quiche 的實作以 now - last_sent_time 計算空閒時長。在 cwnd 最小（2 封包）時，這個計算實際上捕捉到整個 RTT（約 14ms）而非真正的應用空閒期（接近零）。
過度放大的 delta 使恢復起始時間被推到下一個封包發送時間之後，CUBIC 因此誤判為仍在恢復中，跳過 cwnd 增長。這形成自我延續的振盪循環：每 14ms（一個 RTT）觸發一次狀態切換，6.7 秒內振盪 999 次，始終沒有觸發遺失但 cwnd 也始終不成長。
修補
修復方案改為以 max(last_ack_time, last_sent_time) 計算空閒時長，捕捉「自最後一次有意義活動以來的實際間距」，而非 RTT 全長。改動涉及三行代碼，測試通過率從 40% 恢復至 100%。
原始來源：Cloudflare Blog
Browser Run 遷至 Cloudflare Containers：4 倍並發量與 50% 延遲降幅
Cloudflare Blog · 2026-05-13
Cloudflare 的 Browser Run 服務（支援無頭瀏覽器、截圖、PDF 生成、AI agent 網頁互動等）已從共享 Browser Isolation 基礎設施遷移至獨立的 Cloudflare Containers，並發上限提升 4 倍，Quick Actions 響應時間下降逾 50%。
架構演進
舊架構與 Browser Isolation（BISO）共享容器映像和基礎設施，導致啟動慢、全球分布差、BISO 的長連線與 Browser Run 的短突發用量互相干擾。新架構採用區域預熱容器池（Regional Pool）策略：在每個地區預先啟動 Durable Object 支撐的瀏覽器容器，限制 WebSocket 與 Durable Object 之間的最大距離，控制延遲。
狀態管理從 Workers KV（約 30 秒最終一致性，存在競爭條件）改用 D1 資料庫提供事務性原子寫入，確保每個瀏覽器只被一個客戶端取用。透過 Queues 的批量寫入（100 行 / batch）將每個地點的容器容量從 5,000 擴展至 50 萬。
關鍵數據
- 每分鐘瀏覽器啟動量：60（舊架構的 4 倍）
- 並發瀏覽器數：120（舊架構的 4 倍）
- P95 批量寫入延遲：0.1ms
- Quick Actions 響應時間：下降逾 50%
獨立基礎設施也讓 WebGL、WebMCP（Model Context Protocol）支援及 Chrome 版本升級得以快速推進，不再需要跨團隊協調。
原始來源：Cloudflare Blog