测试过程

在测试 1 中，2 核 4G 的 Beacon Chain Node 内存阶段性上升，在运行约 6 小时后，内存使用率达到 100%，导致进程出现内存不足错误被迫停止，同时 CPU 使用率也逐步提高。如下图所示：

图 1

图 2

之后，我们提升了 Beacon Chain Node 的配置为 4 核 8G。

在实例 2-5 中，依次提升验证者数量 1k-10k 来观察服务器 CPU、内存、磁盘 IO、带宽等指标数据，均无压力，也没有异常。

之后我们在不同地区部署 ETH2.0 节点，来观察不同地区的网络互联情况是否会对各指标产生较大影响，实验结果均无异常。

测试小结

根据私网测试情况来看，Beacon Chain Node 建议 4 核 8G 配置，Validator 节点 2 核 4G 的配置够用，但是在导入 key 文件时会占用 1 核 CPU，该 CPU 占用率为 100%（如下图所示），稳妥起见，建议 4C6G 的配置。

图 3

此外，在本阶段的测试中，对磁盘的 I/O 性能和外网带宽要求很低，可能是由于私网的原因，具体的对应的性能要求还需要在 ETH2.0 官方测试网中进行测试。

第二阶段对比测试

测试方案

第一阶段主要测试了不同数量的验证人对于服务器资源的压力，此外，验证者的出块和见证也是也是对于验证人很重要的指标。为此我们进行了对比测试。在同一个网络中，将不同数量的验证人部署在不同的地区来进行对比测试。

测试指标

测试过程中我们将收集各个实例服务器的 CPU、内存、磁盘 IO、网络带宽 IO、应出的块数、实际出块数、应该见证的块数、实际见证的块数等指标。

测试用例

以下为我们的测试用例：

表 2

ETH1.0 网络由三台 2 核 4G 云服务器组成，两台位于香港，一台位于圣保罗。出块时间设置为 15s。

我们分别在香港、新加坡、洛杉矶、法兰克福、圣保罗、伦敦六个地区部署了 Beacon Chain Node 和 Validator Node。各个地区的 Beacon Chain Node 和 Validator Node 通过内网连接。配置和相应的验证人数量如上图。

实例 1 和实例 2 都是 1k 验证人，区别在于 Validator Node 的配置，用于对比不同配置的验证人数量对指标的影响。 (责任编辑：admin)