--- title: "Solana gRPC 性能：公开的基准测试方法" description: "我们如何在六个区域测量 Solana gRPC 的交付延迟，包括 p50、p90 和 p99 结果、完整的测试配置，以及复现结果的具体命令。" --- # Solana gRPC 性能：公开的基准测试方法 Solana 性能数据的价值取决于其背后的测量方法。一个延迟数字如果没有注明区域、时间窗口和测试配置，就无法验证、比较或复现。本文说明我们如何测量我们的 [Solana gRPC 流](https://www.alchemy.com/solana-grpc)，公布这些测量得出的数据，并附上完整配置，让你可以针对任何端点（包括我们的端点）复现测试。 ## 为什么要公开测量方法？单个延迟数字无法说明测试在哪里运行、订阅了什么、使用什么 commitment 级别，以及覆盖了多长的时间窗口。在 Solana 上，这些细节决定了最终数字：区块的产生间隔不到一秒，而各流式端点之间的差距只有几毫秒。我们已经公开了[请求类基准测试背后的测量规则](https://www.alchemy.com/blog/how-we-benchmark-rpc-performance)；本文对 Solana 流式传输做同样的事。任何人都可以通过发送相同的请求来粗略验证请求类基准测试。流则更难检验。你无法重放链上某一时刻的活动，来查看你的服务商是否快速、完整、按顺序地交付了数据。公开的方法让开发者可以针对自己的工作负载重新运行测试，而不必信任某一方的说法。 ## 这个基准测试测量什么？流式传输性能包含三个独立的问题：数据何时到达、是否全部到达，以及连接中断时会发生什么。本基准测试按区域回答第一个问题。 - **网络往返时间（p50）**。从测试机到端点的 TCP 连接时间中位数，基于 30 次连接。它主要由地理位置决定，因此反映的是在任何数据传输之前，你所在位置带来的成本。 - **交付离散度（p90、p99）**。在同一轮测试中，较慢或最坏情况下的消息比最快交付晚多少毫秒到达。尾部才是你的系统在最糟糕时刻感受到的。如果关键的那条更新到得晚了，清算监控程序并不在乎典型更新有多快。我们按区域分别报告这两项指标，从不使用单一的全球平均值。 ## 如何在不依赖时钟的情况下为流计时？为请求计时很简单。由同一台机器发送请求并接收响应，一个时钟就能覆盖整个往返过程。流打破了这种便利。事件起源于验证者，经过服务商的基础设施，最终到达位于另一个数据中心、另一台机器上的订阅进程。这时涉及两个时钟，而不同机器上的时钟即使都运行 NTP，也可能相差几毫秒。运行良好的端点之间的交付差距可能比这还小，这意味着简单的时间戳相减最终测到的可能是时钟误差，而不是性能。我们的端点会为每条消息打上其创建时间的时间戳，测试机用消息到达的时间减去这个时间戳。这个减法比较的是两个时钟，因此测试机在每轮测试前后都会将自己的时钟与公共时间服务器进行校对。仍可能残留一个较小的固定误差。将每条消息相对于本轮最快交付进行报告就可以消除它，因为固定的时钟误差会让每条消息偏移相同的量，在相减时相互抵消。往返时间一列无需校正，因为测试机用自己的时钟为每次 TCP 连接计时。这些数字不能告诉你从验证者到你的进程的总时间，也不用于对服务商排名。排名需要另一种测试，即在同一台机器上比较两个流，复现部分会介绍这一点。有两个细节保证了测量的可靠性。我们将 commitment 级别固定为 `processed`，即最早的确认级别，因为混用 commitment 级别意味着测量的是事件生命周期中的不同时间点。同时，链本身的区块时间戳完全不参与计算。Solana 的出块时间[不到一秒](https://www.alchemy.com/blog/zero-downtime-zero-gaps-solana-grpc-streaming)，而区块时间戳只精确到秒，粒度太粗，无法反映毫秒级的差距。 ## 一轮测试是什么样的？本文中的每个数字都来自具有以下配置的测试。配置发生变化时，我们会以新的日期重新发布数据，而不是直接修改原有数据。 - **被测流**：每轮测试使用单个兼容 Yellowstone 的 gRPC 交易流。 - **监听账户**：PumpSwap，即 Pump 的 AMM 程序，`pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA`，因交易量高而被选中。 - **Commitment 级别**：每轮测试均为 `processed`。 - **样本量**：每个区域 20,000 笔交易。 - **观测点**：在 [Fly](https://fly.io/) 机器上运行的测试机，分布在六个客户端区域：美国东部、美国西部、欧洲西部、欧洲中部、新加坡和东京。每台测试机到端点的往返时间都是其结果的一部分，因为在咖啡店里运行的基准测试，测到的是咖啡店。 - **客户端**：geyserbench 中的 Rust `latency` 示例，使用默认客户端设置并通过 TLS 连接，详见下方的复现部分。 - **时间窗口**：2026 年 10 月 14 日至 16 日。每张公开的表格都会注明产生该结果的测试日期。 ## 结果如何？以下是我们的 Solana gRPC 流的交付表现，分别从各区域的客户端测量。每一行为单个流上的 20,000 笔交易，commitment 级别为 processed，测试时间为 2026 年 10 月 14 日至 16 日： p50 列是从测试机到端点的网络往返时间中位数。p90 和 p99 列表示在该轮测试中，较慢或最坏情况下的消息比最快交付晚多少毫秒到达。可以把 p50 理解为你所在位置带来的距离成本，把 p90 和 p99 理解为交付的稳定程度。两者都不是从验证者开始计算的端到端总延迟。估计自身预期的正确方式是查看你所在区域的那一行：法兰克福的开发者应该看欧洲中部这一行，而不是被测试最快的区域拉低的全球平均值。我们在[推出 Solana gRPC](https://www.alchemy.com/blog/introducing-alchemy-solana-grpc) 时发布过这一结论的早期版本（平均交付速度比其他方案快 5 到 15ms，从 us-east-1 测量）。这张表是那份单区域、正面对比快照的多区域后续版本，采用的是一个不同且互补的指标。 ## 如何复现？你需要 Rust 和一个可以访问 Solana gRPC 的 Alchemy API 密钥（前提条件见[快速入门](https://www.alchemy.com/docs/reference/yellowstone-grpc-quickstart)）。共三条命令：它会打开一个 Solana gRPC 流，在 processed commitment 级别下监听一个繁忙账户上的 20,000 笔交易，并输出到端点的网络往返时间中位数，然后输出你的 p50、p90 和 p99 消息比最快交付晚多少毫秒到达。在你关心的区域中的服务器上运行它，并与上表进行比较。我们使用的是 `pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA`，即 PumpSwap，Pump 的 AMM 程序。它是个不错的选择，因为交易量非常高，20,000 笔交易很快就能到齐。要监听其他程序或运行更短的测试，请将 `ACCOUNT` 设为程序地址，将 `N` 设为交易数量：如果要比较两个服务商而不是测量一个，请在同一台机器上运行两个流，并记录每笔交易由哪一方先交付。公开的 [geyserbench](https://github.com/hmstudio-labs/geyserbench) 可以通过一个列出两个端点的配置文件完成这一操作，并报告每个端点率先检测到交易的频率。如果你运行后得到的数字与我们的有明显差异，请告诉我们。发现这类差异，正是公开方法的意义所在。 ## 这个基准测试不测量什么？有三件事被有意排除在本基准测试之外： - **流的可靠性**。这是一个延迟基准测试。它不测量丢失事件、断连、重连时间或重连后的回填，因此无法证明或否定这些方面的表现。如果你的应用依赖无间隙交付，请直接测试。我们的端点保留 48 小时的历史数据（超过 400,000 个 slot），重连的客户端可以使用 `from_slot` 从中重放。 - **交易上链**。让交易被打包进区块是写入路径上的问题，有其自身的基础设施和故障模式。本文的内容与此无关。 - **请求/响应式读取**。轮询 JSON-RPC 方法是一种不同的访问模式，故障模式也不同，我们的[公开 RPC 基准测试](https://www.alchemy.com/benchmarks)单独覆盖请求流量，并有其自己公开的规则。 ## 常见问题 ### Alchemy 的 Solana gRPC 有多快？这取决于你从哪里测量，因此 Alchemy 按区域公布延迟分布，而不是给出单一的全球数字。上方的区域表格列出了网络往返时间以及 p90 和 p99 交付离散度，这些数据由公开的方法在注明的日期测得。到端点的网络往返时间从美国东部的 1.8 ms 到欧洲西部的 21.9 ms 不等，p99 消息根据区域不同，会在最快交付之后 6.8 至 23.6 ms 内到达。 ### 如何测量 Solana gRPC 延迟？每个区域的客户端以 `processed` commitment 级别打开一个 gRPC 流，监听一个高交易量程序上的 20,000 笔交易，并将每条消息的到达时间与我们的端点创建该消息的时间进行比较。结果按区域报告，指标为相对于本轮最快交付的 p90 和 p99 延迟，同时列出从客户端到端点的网络往返时间中位数。 ### 我可以复现 Alchemy 的 Solana gRPC 基准测试吗？可以。测试使用 geyserbench 中的 `latency` 示例运行，具体命令已在本文中公开。在你的服务区域中的服务器上以 `processed` commitment 级别运行它，并将你的百分位数与区域表格进行比较。如果要比较两个服务商，geyserbench 还可以在同一台机器上并行运行两个端点。 ### 基准测试使用什么 commitment 级别？每轮测试都以 `processed` 订阅，这是 Solana 最早的 commitment 级别。混用 commitment 级别会在事件生命周期的不同时间点测量事件，使百分位数失去意义。你的生产应用可能更倾向于使用 `confirmed` 或 `finalized`；本方法保持 commitment 级别不变，以便数据在不同区域和不同轮次之间保持可比。 ### 这是与其他服务商的对比吗？不是。本文说明的是 Alchemy 如何测量并公布自己的 Solana gRPC 性能。其他服务商也会发布自己的基准测试，这一领域公开的方法越多，对所有人越有利。复现部分的目的，是让你能够亲自在自己的工作负载上运行真正重要的对比。 ## 开始流式传输 Solana 数据我们的 [Solana gRPC 流式服务](https://www.alchemy.com/solana-grpc)兼容 Yellowstone，因此将现有客户端指向它只需修改一个 URL，而无需重写代码。价格为每 TB 75 美元，没有月度最低消费，[Yellowstone gRPC 文档](https://www.alchemy.com/docs/reference/yellowstone-grpc-overview)提供了快速入门指南。在 Solana 上构建的团队还可以通过 [2000 万美元 Solana 基金](https://www.alchemy.com/solana-20m-fund)申请最高 2.5 万美元的额度。你也可以先运行基准测试，这正是它的用途。