Go-Quai项目中WebSocket订阅性能测试与分析

引言

在区块链基础设施的构建中，RPC节点的资源规划是一个关键环节。Go-Quai项目团队近期针对WebSocket订阅功能进行了系统的性能测试，目的是评估在高并发场景下节点的资源消耗情况，特别是针对Pelagus钱包这类典型用户场景。

测试背景

Pelagus钱包作为Go-Quai生态中的重要组件，其用户主要通过WebSocket订阅来获取余额更新通知。这种模式相比传统的HTTP轮询，在实时性方面有明显优势，但也带来了新的性能挑战。

测试目标演进

最初的测试计划经历了几个阶段的演进：

1. 初期目标：简单测量每个活跃WebSocket连接加上余额订阅的内存占用(MiB/用户)
2. 深化理解：对比HTTP轮询与WebSocket订阅在内存和带宽消耗上的差异
3. 最终方向：在启动节点配置下，重点测试事件处理延迟与并发订阅量的关系

测试方法与发现

内存占用测试

团队首先进行了基础内存占用测试，结果令人意外：

• 基线内存：4.1GB
• 100万订阅者：4.5GB
• 200万订阅者：4.7GB
• 300万订阅者：4.7GB

数据表明，单纯增加订阅数量对内存的影响微乎其微，这与传统WebSocket服务器的预期行为有所不同。

性能瓶颈转移

进一步的测试揭示了真正的瓶颈所在：

1. 事件处理延迟：当大量订阅同时收到事件通知时，消息分发成为主要性能瓶颈
2. TPS影响：在2000TPS的网络环境下，假设10%交易影响Pelagus用户，意味着每秒需要处理约200个余额更新事件
3. 开发者场景：特殊用例(如QuaiMark)可能产生更高频的事件，需要单独评估

技术启示

这些发现为架构设计提供了重要参考：

1. 资源规划：节点规格应基于预期的事件处理能力而非简单的连接数
2. 优化方向：需要重点优化事件分发机制，而非单纯扩展连接容量
3. 场景区分：普通用户与开发者用户可能需要不同的服务质量策略

后续工作

测试过程中也遇到了一些技术障碍，特别是关于EOA账户余额更新事件的RPC实现问题。团队正在完善相关功能，以便进行更全面的性能评估。

结论

Go-Quai项目的这次性能测试揭示了在高并发WebSocket订阅场景下，传统以连接数为核心的资源评估方法可能失效。真正的系统瓶颈往往出现在事件分发机制而非连接管理上，这为区块链基础设施的性能优化提供了新的思路方向。