基准测试

性能基准测试:在 $5 VPS 上运行多链加密货币支付网关

2026 年 5 月 31 日阅读时间约 10 分钟

一个功能完备的多链加密货币支付网关能在 $4.49/月的 VPS 上运行吗? 我们对 XPay Labs 进行了严格的基准测试。简短的回答:可以——而且还有余力处理 10,000+ 并发发票。以下是数据。

测试环境

组件规格
提供商Hetzner Cloud CX22
vCPU2 (AMD EPYC)
内存4 GB
存储40 GB NVMe SSD
操作系统Ubuntu 24.04 LTS
Docker26.1
成本$4.49/月
扫描的链TRON (TRC-20) + Ethereum + BNB Chain + SUI — 同时扫描

关键指标

<500ms
支付检测延迟(TRON)
~120 MB
内存占用(全部链)
10,000+
并发发票容量

1. 支付检测延迟

这是支付网关最重要的指标:从客户发送交易到网关触发确认 webhook 之间经过多少时间。 我们在 7 天内用 5,000 笔测试交易测量了所有支持链的延迟。

p50 延迟p95 延迟p99 延迟区块确认阈值
TRON210ms480ms820ms19 块(约 57s)
Ethereum340ms890ms1.4s12 块(约 2.5min)
BNB Chain180ms410ms720ms15 块(约 45s)
SUI95ms280ms510ms即时(0 块)

注:"检测"测量的是从区块包含到 webhook 分发的时间,而非区块确认时间。 确认时间(等待 N 个区块)为每条链增加了可预测的延迟,并可在部署时配置。

2. 资源消耗

我们在三种场景下测量了 CPU 和内存:空闲(仅扫描)、峰值负载(1,000 并发支付)、 突发(包含 50+ 相关交易的区块触发 webhook 分发风暴)。

场景内存CPU(每条链)Docker 镜像磁盘 I/O
空闲(4 条链)~120 MB<1% 每条<40 MB可忽略
峰值(1,000 笔交易)~280 MB~15% 总计<40 MB~2 MB/s(SQLite 写入)
突发(webhook 风暴)~350 MB~40% 总计(短暂)<40 MB~8 MB/s(突发)
关键结论: 即使在突发负载下,XPay Labs 在廉价 VPS 上的 内存使用也不超过 400 MB,CPU 使用低于单核的 50%。这为同一台机器上的应用程序、 数据库和反向代理留下了充足的余量。

3. Webhook 交付可靠性

Webhook 是支付自动化的核心。如果 webhook 丢失,订单将无法完成。 我们使用 50,000 次交付测试了 XPay Labs 的 webhook 分发系统。

99.7%
交付成功率
<200ms
p50 交付时间
3
重试次数(10s、60s、300s)

0.3% 的失败完全来自目标服务器返回非 2xx 状态码(502、503)。 经过 3 次指数退避重试后,交付成功率达到 99.97%。建议在端上实现死信队列, 以应对服务器长时间宕机的罕见情况。

4. 与托管方案对比

XPay Labs 与托管网关的性能对比如何?虽然我们无法对 BitPay 内部基础设施做基准测试, 但可以从商户角度比较可观察的指标。

指标BitPayCoinbase CommerceXPay Labs
检测延迟~30s–2min~10s–1min<500ms
API 响应(p95)~200–500ms~100–300ms<50ms(本地网络)
结算速度T+1 到 T+3 天T+1 天即时(链上)
平台运行时间 SLA99.9%(SaaS)99.9%(SaaS)你的运行时间 = 你的控制力
方法论: 所有 XPay Labs 基准测试在 Hetzner CX22 (2 vCPU, 4 GB RAM, 40 GB NVMe, Ubuntu 24.04, Docker 26.1)上运行。 支付检测延迟从区块包含时间(通过 RPC 追踪)到 webhook POST 完成测量。 CPU 通过 docker stats 和 /proc/stat 测量。内存通过 JVM Runtime.totalMemory() - freeMemory() 测量。 交易量使用网关的负载测试工具模拟,该工具生成 10-1,000 个并发发票创建和测试网上的匹配链上交易。 完整原始数据可在 github.com/xpaylabs 获取。

运行你自己的基准测试

不要只听我们说。在 $5 VPS 上部署 XPay Labs,自己运行基准测试套件。 网关包含内置 Prometheus 指标端点,负载测试工具是开源的。