Alchemy 与 QuickNode：可复现的 RPC 评估方法

范围与您实际正在做的决策

在 Alchemy 和 QuickNode 之间选择是一个关于运营契合度的决策，而不是单一分数。两家提供商都通过 HTTPS 和 WebSocket 提供 JSON-RPC，都提供基于用量计量的付费层级，并且都捆绑了增强 API，例如代币、NFT 和追踪端点。在生产环境中真正重要的差异通常更窄：您需要哪些链和归档深度，每个提供商如何计量像 eth_getLogs 和 debug_traceTransaction 这样的昂贵方法，速率限制在突发流量下如何表现，以及当某个区域性能下降时支持响应有多快。

本文不对两家提供商进行排名。它描述了一种您可以在一个下午内运行的测量方法，然后解释如何解读输出。如果您想要针对特定链的具体端点推荐而不是方法论，RPC Assistant 的答案是合适的起点；本页介绍如何根据您自己的流量验证任何推荐。

• 假设：您已经拥有两家提供商的试用或付费访问权限，并且可以从至少两个区域发出请求。
• 假设：您知道按量计算的前五个 RPC 方法以及峰值每秒请求数。
• 范围之外：专有基准数据集和任何供应商自行发布的延迟声明。

心智模型：将传输层与产品层分开

托管 RPC 提供商位于您的应用程序和节点集群之间。传输层是您可以直接测量的部分：连接建立、首字节时间、完整响应时间、HTTP 状态码和 JSON-RPC 错误对象。产品层是围绕它的一切：仪表板、webhooks、增强端点、SDK 和账户抽象工具。大多数比较文章将两者混在一起，这使得结果难以采取行动。

将它们分开。使用原始 JSON-RPC 调用对传输层进行基准测试，这样您比较的是基础设施，而不是 SDK 开销。通过列出您的应用程序实际调用的增强端点并确认每个提供商在您的目标链上支持它们，来单独评估产品层。一个在延迟上胜出但缺少您依赖的归档方法的提供商不是一个可行的选择，而一个工具更丰富但 p99 延迟不稳定的提供商仍可能无法满足交易工作负载。

在接触端点之前定义工作负载配置文件

没有工作负载配置文件的基准测试会产生无法迁移的数字。首先写下请求组合。对于典型的 DeFi 仪表板，组合可能是 60% eth_call、20% eth_getBalance、10% eth_getLogs、5% eth_getBlockByNumber 以及 5% 追踪或归档读取。对于索引器，eth_getLogs 和归档读取占主导。对于钱包，eth_getTransactionReceipt 和 eth_getTransactionCount 更重要。

记录链、您的用户连接的区域以及您的峰值和平均每秒请求数。此配置文件将成为基准测试脚本和稍后成本模型的输入。没有它，您最终会比较与您实际账单关系不大的头条月度配额。

• 按调用量计算的主要方法，以及代表性的参数负载。
• 链和网络，包括您部署所在的测试网。
• 所需的归档深度，如果需要任何历史状态读取。
• 调用者的地理分布以及任何数据驻留限制。
• 峰值 RPS、突发持续时间以及可接受的 p95 和 p99 延迟。

使用 curl 构建可运行的延迟测试工具

这为您提供了一个粗略的分布并确认身份验证正常工作。它不足以进行真正的比较，因为在低延迟下 curl 进程启动占主导地位。对于实际测量，请转向持久连接客户端。

for i in $(seq 1 20); do
  curl -s -o /dev/null -w "%{http_code} %{time_total}\n" \
    -X POST "$RPC_URL" \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'
done

使用持久连接脚本测量百分位数

对每个负载至少运行几百次，分散在不同时间段。在记录每个结果的同时记录区域、时间戳和提供商。如果您需要更广泛地了解端点选择如何与链选择相互作用，多链 RPC 端点指南涵盖了网络维度。

import json, time, statistics, urllib.request

PROVIDERS = {
    "alchemy": "ALCHEMY_RPC_URL",
    "quicknode": "QUICKNODE_RPC_URL",
}
PAYLOADS = [
    {"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]},
    {"jsonrpc":"2.0","id":2,"method":"eth_getBalance","params":["0x0000000000000000000000000000000000000000","latest"]},
]

def run(url, payload, n=200):
    samples, errors = [], 0
    for _ in range(n):
        body = json.dumps(payload).encode()
        req = urllib.request.Request(url, data=body, headers={"Content-Type":"application/json"})
        start = time.perf_counter()
        try:
            with urllib.request.urlopen(req, timeout=10) as resp:
                data = json.loads(resp.read())
            elapsed = (time.perf_counter() - start) * 1000
            if "error" in data:
                errors += 1
            else:
                samples.append(elapsed)
        except Exception:
            errors += 1
    samples.sort()
    def pct(p):
        return samples[min(len(samples)-1, int(len(samples)*p))] if samples else None
    return {"n": len(samples), "errors": errors, "p50": pct(0.50), "p95": pct(0.95), "p99": pct(0.99)}

for name, url in PROVIDERS.items():
    for payload in PAYLOADS:
        print(name, payload["method"], run(url, payload))

将结果记录在比较表中

预期的验证结果是重复运行中保持稳定的排序。如果 p95 在连续运行中在提供商之间翻转，您的样本量太小或您的区域噪声太大。在得出结论之前增加样本数量，并保留原始数据，以便在提供商更改基础设施后重新查看。

• | 提供商 | 链 | 区域 | 方法 | 样本数 | 错误数 | p50 (ms) | p95 (ms) | p99 (ms) |
• | Alchemy | Ethereum | eu-west | eth_blockNumber | (测量值) | (测量值) | (测量值) | (测量值) | (测量值) |
• | QuickNode | Ethereum | eu-west | eth_blockNumber | (测量值) | (测量值) | (测量值) | (测量值) | (测量值) |

测试突发下的速率限制和错误行为

在相同的并发下对两家提供商运行此测试，并比较状态码的分布。一个返回干净的 429 并带有重试提示的提供商比一个静默丢弃连接的提供商更容易运营。

import concurrent.futures, json, urllib.request

def call(url):
    body = json.dumps({"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}).encode()
    req = urllib.request.Request(url, data=body, headers={"Content-Type":"application/json"})
    try:
        with urllib.request.urlopen(req, timeout=5) as r:
            return r.status, r.headers.get("Retry-After")
    except urllib.error.HTTPError as e:
        return e.code, e.headers.get("Retry-After")

url = "RPC_URL"
with concurrent.futures.ThreadPoolExecutor(max_workers=50) as pool:
    results = list(pool.map(lambda _: call(url), range(500)))
from collections import Counter
print(Counter(results))

验证目标链上的方法和归档覆盖范围

如果某个方法不受支持，延迟就无关紧要。根据您的工作负载配置文件构建覆盖矩阵：对于每个方法，确认在每个链和每个提供商上的支持情况。特别注意归档读取、追踪和调试命名空间、eth_getLogs 区块范围限制以及 WebSocket 订阅行为。直接测试每一个，而不是仅仅依赖文档，因为即使在同一提供商内，支持也可能因网络而异。

对于专用或单租户容量，检查提供商是否提供隔离节点以及在哪些区域；专用节点模型会改变延迟和成本。如果您的工作负载跨越许多链，网络目录可帮助您在承诺选择提供商之前确认哪些网络可用。

将测量结果转化为成本模型

两家提供商都按用量计量，但单位和乘数不同。根据您的工作负载配置文件构建成本模型：将每个方法的月度调用量乘以该提供商对该方法的权重，对加权单位求和，并与计划配额和超额费率进行比较。单独包括 WebSocket 消息量和任何增强 API 调用，因为这些通常按不同的尺度计费。

不要跨提供商比较头条月度请求数。如果您的流量主要由加权方法主导，一个包含大量廉价读取的计划仍然可能比一个较小的计划更昂贵。RPC 定价页面展示了 OnFinality 如何构建计划，这在构建模型时作为第三个参考点很有用。

• 每月加权单位 = 各方法的（调用次数 × 方法权重）之和。
• 有效成本 = 计划价格 + max(0, 加权单位 − 包含单位) × 超额费率。
• 将支持层级和 SLA 承诺作为单独的行项目添加，而不是混入每请求成本。

排查常见的基准测试伪影

大多数误导性的比较来自少数可避免的错误。如果您的结​​果看起来不可信，请先检查这些。

• 冷连接：对新端点的第一个请求需要支付 TLS 和连接建立成本。丢弃预热请求。
• DNS 和代理效应：企业代理和 VPN 会增加与提供商无关的延迟。从干净的主机进行测试。
• 负载差异：latest 区块标签比特定历史区块更频繁地命中缓存。保持跨提供商的负载相同。
• 小样本：每个方法和区域少于几百个样本不会产生稳定的 p99 值。
• 时钟偏差：使用单调计时器计算经过时间，而不是挂钟时间戳。
• 静默错误：包含 JSON-RPC 错误的快速响应不是成功的样本。单独分类错误。

局限性以及何时停止测量

基准测试是一个快照。提供商基础设施、路由和定价会变化，一周的结果可能下一周就不成立。将测试工具视为定期检查而不是一次性决策，并在任何计划变更或事件后重新运行它。还要接受没有本地基准测试能完全复现生产流量：您的真实应用程序具有测试工具没有的缓存、批处理和重试逻辑。

如果两家提供商在延迟和可靠性上彼此在噪声范围内，决策应转向产品契合度、支持响应能力和合同条款。此时，进一步的微基准测试收益递减。对于希望获得具有可预测计量的托管替代方案的团队，API 服务概述描述了 OnFinality 如何进行端点配置。

后续步骤：将比较操作化

将测试工具转变为定期作业，每周从您的主要区域运行，并将结果存储在时间序列表中。当 p95 或错误率超过您根据自身基线设置的阈值时发出警报。随着应用程序的发展保持工作负载配置文件最新，并在任一提供商更改其定价页面时重新审视成本模型。

如果您仍在缩小特定链或端点的范围而不是完整的提供商比较，请从 RPC Assistant 获取直接推荐，然后使用上述测试工具进行验证。对于构建更广泛基础设施计划的团队，区块链节点托管指南涵盖了运行和监控节点的运营方面。