我們如何微調 RPC 以提升速度與可靠性

我們非常重視效能,並持續微調以進一步優化我們的平台。我們最近改變了平台壓縮大型 RPC 回應的方式,其中一項改動對 Worldchain 產生了格外顯著的效果。大型呼叫的壓縮回應現在快了約 33%,這代表更快的完整區塊讀取與其他高負載呼叫、更穩定的效能,以及更多應對流量成長的餘裕。

什麼是 GOAWAY frame?

如果你在 HTTP/2 上運行高吞吐量的工作負載,即使從未查過資料,你也應該聽過 GOAWAY frame。GOAWAY 是伺服器發送給客戶端的訊號,告訴客戶端停止在某連線上開啟新的 stream,通常是因為伺服器正在卸載負載。對客戶端來說,一連串的 GOAWAY 會表現為連線頻繁中斷:stream 被切斷、請求在新連線上重試、尾端延遲上升。

GOAWAY 變少代表連線更穩定、重試更少、服務更快。所以當某個客戶的 GOAWAY 數量驟降時,代表上游有某個環節突然多出了不少餘裕。在這個案例中,那個環節就是 CPU。

壓縮原本在哪裡執行

我們回傳的每一個 RPC 回應在離開我們的網路之前都可以被壓縮。大多數 HTTP 客戶端會透過發送 Accept-Encoding: gzip 標頭來請求這項功能,而大多數網頁伺服器,包括我們自己的 node-gateway,都會自動遵循這個標頭。這不是我們特別打造的功能,而是標準行為。對於大型 payload,例如完整區塊讀取或大量 eth_getLogs 結果集,壓縮能明顯減少透過網路傳送的位元組數,這一點很重要,因為網路頻寬有限。

長久以來,在 node-gateway 中進行壓縮是合理的做法。Node-gateway 是一個 IO-bound 的服務:它大部分時間都花在等待網路呼叫,不論是來自客戶還是我們自己的節點,所以它過去一直有多餘的 CPU 可用。壓縮是CPU-bound 的工作,其成本會隨回應大小增加。在規模擴大後,壓縮成了 gateway 最忙碌、對延遲最敏感的工作之一,與 gateway 路由及服務每個請求所需的 CPU 互相競爭。

當 gateway 過熱時,它執行的每件事都會同時變慢。而負載下 gateway 的 CPU 壓力,正是觸發連線卸載與 GOAWAY frame 的條件。

我們改了什麼?

我們把資料壓縮的執行位置從 node-gateway 移到了服務網格中的 Istio proxy。Node-gateway 不再壓縮回應。這項工作現在改在另一個步驟中,由更適合的基礎設施上的 Istio proxy 執行。這樣一來,Alchemy 的 node-gateway 就能專心優化速度與可靠性,而壓縮這個步驟則交由 Istio 處理。

結果是客戶收到的壓縮回應完全相同,只是由更能有效率完成這項工作的地方產生,且不需要與決定效能的那一跳爭奪運算資源。同樣的技術堆疊、同樣的輸出,只是換了個更好的地方執行。

這對你代表什麼?

大型呼叫的壓縮回應現在快了約 33%(P95 延遲改善約 35%)。這可以拆解成三件事。

**連線更穩定。**當處理你請求的那一跳不需要爭奪 CPU 時,它就不會再卸載負載,於是你會遇到更少的 GOAWAY、更少的 stream 中斷,以及更少被迫的重試。這正是 Worldchain 觀察到的情況:連線錯誤從每小時約 1,500 次降到約 100 次。

**你的重負載呼叫回應更快。**在 Istio proxy 上處理壓縮,讓大型回應的第一個位元組能更早送出。對於完整區塊讀取或大量 eth_getLogs 結果集這類大型 payload 來說,這代表回應第一個區塊抵達所需的時間縮短了。

**底層有更多餘裕。**我們在決定你效能的那一跳上釋放出了可觀的 CPU 容量。這項改善是以每個請求為單位生效的,所以隨著你的流量成長,效果依然持續。你不需要做任何改動就能受益,它已經在你發送的每個請求底下運作。

為什麼這很重要

讓一個 RPC 供應商既快速又可靠的大部分因素,都發生在你看不到的地方,就像這一跳一樣。單一服務在正確的地方減少做錯的事,一夜之間就轉化為更穩定的連線與更快的回應,而客戶端完全不需要做任何改動。

這只是我們持續改善服務路徑的其中一項改動。開始在 Alchemy 上建構。