可以看到，实例 3 中大多数验证人的见证率都不高，这也意味着实例 3 应该出了问题。

为此，我们检查了实例 3 的日志，发现 Beacon Chain Node 与其它节点以及 ETH1.0 的连接并不稳定，猜测是由此导致了见证率的异常，有待后续检验。

服务器压力

在本轮测试中，我们观察到如下表的性能指标数据：

表 6

Beacon Chain Node

实例 1-5 中，Beacon Chain Node 的 CPU 使用率在 5%-10% 之间，实例 6 的 Beacon Chain Node 的 CPU 使用率约为 12%。内存方面呈现平稳增加，在 12%-17% 之间，磁盘 IO 与带宽无明显差异。

Validator Node

随着验证者数量的增加，Validator Node 的各项指标均平稳增多，可以看到，磁盘 IO 与带宽基本上正比于验证者的数量。

此外，生成验证者密钥文件方面，我们采用的是一个推荐的 python 命令行 工具，该工具生成密钥的效率相对不高，在多核的机器上只占用 1 核，生成 2000 个密钥对需要 2.5 小时左右。另一方面，Validator Node 导入密钥对也是单核执行，导入 2000 个密钥对的时间大约为 40 分钟。

测试小结

通过本轮测试，我们在私有网络中观察到，验证人数量的增加会影响节点上所有验证人的出块率，对于单个验证人来说，在最好的情况和最坏的情况下，平均每天少见证约 10 个块。出块方面在我们的测试中并未发现不同。内存与磁盘 IO 的使用率相对于 CPU 和带宽，更加明显地随着验证人数量的增加而提升。

后续测试方案和待优化步骤

在本轮测试中，以下几方面占据较多的准备时间：

• 验证者密钥对生成
• 部署 deposit 合约
• Validator Node 导入密钥对

在后续方案中，计划对上述步骤采取优化，提高测试效率。

此外，在后续测试计划中，考虑到不同地区的网络之间的稳定性及其对验证人指标的影响，可以考虑以下几点改进： (责任编辑：admin)