為什麼 VPS 能實現高效能？ERPC 的架構解析

當開發者開始在 Solana 上構建應用或機器人時，許多人基於過往經驗自然而然地選擇大型通用雲。在 Web2 的世界裡，這些雲實際上已經成為標準，並且提供了足夠的效能。因此，假設同樣的方法也適用於 Solana 是很自然的。

然而，這一假設在 Solana 工作負載中嚴重失效。大型通用雲以通用性和靈活性作為最高優先順序來設計，對於像 Solana 這樣低延遲直接影響結果的工作負載，結構性差異會立即顯現。

本文以循序漸進且細緻的方式解釋了為什麼 Solana 工作負載在大型通用雲上無法達到預期效能，以及 ERPC VPS 是如何在結構上解決這些問題的。

為什麼"雲慢"在 Web2 中幾乎不會被注意到

首先，大多數 Web2 應用不像金融應用那樣關鍵。 SNS、電子商務、商業工具和內容分發等服務可以容忍一定程度的延遲，仍然能作為產品執行。

因此，大型通用雲內部以下結構性延遲來源不會作為問題浮現：

多層虛擬化（虛擬網絡卡、虛擬交換機等）
許多使用者共享的內部頻寬
CPU 超額分配（分配比物理核心更多的虛擬核心）
計費和監控的額外程序
向普通使用者提供的較老 CPU 代次

這些機制對於雲運營是必要的，但在 Web2 工作負載中其影響很小，幾乎沒有機會注意到它們。

Solana 工作負載根本不同。

Web3 應用處於"金融相鄰"位置，一切都可能變為關鍵任務

建立在 Solana 和其他區塊鏈上的應用處於金融領域的附近。資產轉移、清算條件、價格變動和交易排序都直接與結果掛鉤。

特別是，與市場相關的工作負載需要遠超傳統卡支付的交易量和速度。即使幾毫秒的延遲也可能導致執行失敗或更差的定價。

此外，Solana 的鏈上資料量極大；正確訂閱 Shreds、日誌和 gRPC 事件可以輕鬆導致每天數 TB 的資料。這與大型雲最初設計用於的典型 Web2 流量模式根本不同。

這樣，Solana 不提供任何機會來隱藏這些雲內部存在的結構性延遲或成本特徵。從一開始，這些特徵就直接表現為劣勢或運營成本。

為什麼大型通用雲不適合 Solana

下面我們逐因素解釋為什麼大型通用雲與 Solana 的高速要求在結構上不匹配。

1. 普通使用者可用的 CPU 是幾代之前的

大型雲提供的裸金屬伺服器和 VPS（VM）通常使用落後幾代的 CPU。最新的高主頻 CPU 不符合提供商的運營效率或庫存策略，因此很少作為使用者可選選項出現。

對於 Solana 工作負載，單執行緒效能和快取結構很重要，CPU 代次差異影響：

可以處理多少交易
可以處理多少流而不落後
資料處理速度有多快

2. 多層虛擬化和長網路路徑（更高的網路延遲）

大型通用雲必須在共享物理硬體上同時執行許多不同的應用。為了支援這一點，新增了多個虛擬化和內部網路層。

例如：

執行虛擬機器的 hypervisor
虛擬網絡卡和交換機
內部防火牆和負載均衡器
計費和監控代理

雖然對雲運營來說是必要的，但從 Solana 的角度來看：

每一個都延長了網路和處理路徑
每一個都引入了延遲和抖動

對於持續處理 Shreds 或 gRPC 等流資料的工作負載，這些"額外中轉點"直接累積為劣勢。

3. 超額分配造成不穩定的效能

大型雲透過在一臺物理伺服器上執行許多虛擬機器來提高效率。例如，一臺 64 核物理 CPU 的伺服器可能託管許多 8 核或 16 核虛擬機器，加起來遠超 64 個虛擬核心。

這種做法——分配比物理核心更多的虛擬核心——就是超額分配。

假設是：

不是所有虛擬機器都會同時使用 100% 的 CPU
CPU 時間可以根據活動情況在虛擬機器之間借用

對於 Web2 工作負載，這些假設是合理有效的。

然而，Solana 工作負載通常包括多個同時需要大量 CPU 的程序。在超額分配的伺服器上，CPU 競爭更頻繁發生，作業系統必須將任務排隊排程。

因此：

基準測試可能看起來很快
實際工作負載中的真實延遲根據時段和其他租戶的負載顯著變化

對於 Solana 來說——交易時序和流處理時序直接影響結果——這種抖動是一個重大劣勢。

4. 高資料傳輸量導致昂貴的按使用量計費

認真監控 Solana 鏈上資料經常涉及每天透過 Shreds、日誌和 gRPC 事件傳輸數 TB 的資料。

大型雲對以下內容分別收費：

出站網路流量
有時內部網路流量
儲存 I/O

在 Web2 工作負載中，這些費用微不足道，因為流量小。但對於 Solana 工作負載，僅訂閱流就可能導致每天數百美元的網路費用，使持續運營變得不切實際。

因此，大型通用雲在結構和經濟上與 Solana 工作負載不匹配。

為什麼 ERPC 在全球測試資料中心

理解這些約束後，我們需要找到實際適合 Solana 的基礎設施。

為此，我們在全球租賃資料中心並執行真實的 Solana 工作負載來評估其行為。

即使在同一城市內，對 Solana 的適用性也會因以下因素而不同：

建築結構
機櫃位置
內部佈線
IX 和 transit 提供商
網路硬體效能和配置
ISP 容量和路由質量
物理光纖路由的數量和質量
擁堵時的頻寬保證

透過反覆測試，我們清楚地識別出：

對 Solana 行為一致且協作良好的位置
不管宣傳規格如何都不適合的位置

我們移除了後者，一次又一次地完善選擇，最終形成了當前的基礎設施和網路架構。這些積累的知識直接支撐著 ERPC VPS 和 RPC 基礎設施的基礎。

為什麼 ERPC VPS 能提供高效能

以下解釋了 ERPC VPS 如何在結構上支援高效能 Solana 工作負載。

透過專注 Solana 工作負載移除不必要的層

大型通用雲包含許多層來支援各種應用。其中大多數對 Solana 不提供直接價值，反而造成延遲。

透過專注於 Solana 工作負載，ERPC VPS 以仔細和可控的方式逐一移除：

Solana 流量不需要的層
僅用於多用途雲運營的元件

這不是"為了簡化而簡化"，而是一個設計原則：只保留對 Solana 有意義的東西，移除其他一切。

無超額分配

Premium VPS 從不超額分配物理 CPU 核心。每個分配的核心直接由物理核心支援。

這避免了：

效能因其他租戶而變化
重負載下的 CPU 競爭

Standard VPS 也將超額分配率保持在極低水平，以確保穩定的 CPU 行為。

CPU 始終以最大睿頻執行

許多伺服器環境出於功耗或散熱原因動態調整 CPU 頻率。然而，對於 Solana 工作負載，這種變化可能在關鍵時刻導致效能下降。

ERPC VPS 經過調優，使 CPU 以持續的高主頻執行，最小化負載下的向下波動，確保效能穩定性。

執行在 Solana 的關鍵網路樞紐上

ERPC VPS 不僅僅是"位於我們自己的基礎設施附近"。它直接執行在 Solana 驗證者和質押在全球集中的網路上。

Standard VPS 部署在全球驗證者數量和質押量排名第二的網路上。 Premium VPS 執行在這兩個指標全球排名第一的網路上，直接連線到 leader 和核心驗證者匯聚的主要樞紐。

因此，ERPC VPS：

與 ERPC 的 RPC、gRPC 和 Shredstream 基礎設施共享同一網路，並且
執行在驗證者和質押最為集中的網路上

這使工作負載在物理和邏輯上更接近 leader。

因此，即使相同的程式碼和邏輯，在 ERPC VPS 上執行與在大型通用雲上執行相比，會表現出結構性不同的效能——尤其是在 leader 相鄰的檢測和交易提交方面。

RAID0 儲存配置

許多雲和 VPS 提供商優先考慮資料保護，因此使用 RAID10 或 RAID4/5/6。對於使用者資料駐留在伺服器上的 Web2 系統，這是合適的。

然而，許多 Web3 應用和 Solana 節點在應用層不保留任何不可替代的資料。區塊鏈本身作為分散式賬本，使重新同步或重建成為可能。

許多使用者也更偏好效能而非映象，儲存 I/O 效能直接影響 Solana 節點行為。因此，ERPC VPS 使用 RAID0 來最大化 I/O 吞吐量。

在 Web3 基礎設施中，選擇在哪裡放置冗餘以及在哪一層是平衡效能和安全的關鍵。

參考：不同 SSD RAID 級別的實際速度測試 https://larryjordan.com/articles/real-world-speed-results-for-different-raid-levels/

總結

沒有單一因素能解釋 ERPC VPS 的效能。

CPU 代次、超額分配策略、消除節能約束並以最大睿頻執行、資料中心選擇、網路路徑、RAID 配置，以及為 Solana 工作負載移除不必要層的程度——這些因素中每一個單獨看可能很小，但當每一個都被徹底最佳化時，累積效果就是 ERPC VPS 今天交付的效能。

透過這些努力，我們構建了一個與大型通用雲根本不同的基礎設施——一個專為 Web3 和區塊鏈工作負載最佳化的基礎設施。對於 Solana 來說，這種結構性差異直接轉化為有意義的效能優勢。

如有配置諮詢、用例討論或部署規劃，請隨時透過 Validators DAO Discord 聯絡我們。

ERPC 官方網站：https://erpc.global/
Validators DAO 官方 Discord：https://discord.gg/C7ZQSrCkYR