为什么 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