概述
OneLedger TechnologyInc.作为一家公司，旨在提供一种通用协议，实现各种区块链之间的互操作性。我们的目标是成为第一个真正可互操作的区块链，重点关注可扩展性和容错性。我们使用Tendermint作为我们的共识引擎。 Tendermint为我们提供了拜占庭式容错状态机，可以承受网络中1/3机器的故障。
我们独特的方法帮助我们轻松地为公共权限和私人许可区块链提供便利。
我们最近进行了负载测试，作为测试公共区块链有效性的持续努力的一部分。本文旨在详细讨论公共区块链的负载测试方法和指标。
目标
1.讨论负载测试方法
2.解释负载测试结果需要进行负载测试OneLedger建立在使用PBFT共识模型的Tendermint共识层之上。 OneLedger协议从中受益于构建委托证明(DPoS)模型。验证者持有OLT以获得成为块提议者的机会。该模型比PoW模型快得多，其中参与节点竞争解决复杂的数学难题以成为块提议者。在每个块提交之前，Tendermint
经历了4个阶段(建议，预投票，预提交和提交)。在每个阶段中，在所有验证器之间交换了许多消息。
OneLedger致力于为社区提供最佳体验。在这方面，我们非常重要的是要弄清楚网络在不同负载条件下的表现。这有助于我们为未来的里程碑(如主网)做好充分准备。 负荷试验方法此负载测试在Google Cloud Platform上执行。我们使用的所有VM都有8个CPU和16 Gb RAM用于此负载测试。我们已经尝试了不同的验证器数量和Mempool。块大小设置为21 Mb，每个事务的事务大小大约为186字节，这意 味着一个块可以容纳超过110,000个事务。如上所述，Tendermint每个块经历4个阶段，作为其提交过程的一部分。每个阶段的时间隔设置为以下值:
1.建议 - 3秒(每个验证器最多等待3秒，以便建议新的块)
2.预投票 - 1秒(每个验证员等待其他验证者的投票最多1秒)
3.预提交 - 1秒(每个确认者最多等待1秒钟以接收所有预先提交)
4.提交 - 1秒(每个Validator在提交一个块后等待1秒，这意味着块时间隔至少为1秒)
我们从2个验证器开始，并在Mempool中测试Mempool中的许多事 务，从100,1000,5000,10000,50000和100000不等。我们用4,8,16,32和64个验证器重复相同的测试。 对于每个测试，我们在所有验证器上同时以每秒1000-4000个事务轰击每Validator。 结果验证器的数量绘制在X轴上，每秒事务数(TPS)绘制在Y轴上。每行代表具有不同值的Mempool配置。
推理
我们一直在达到超过4000的TPS。虽然这里的优点是这个TPS只是我们的主链。通过我们的侧链，我们可以为每个侧链提供4000的TPS。因此，我们有能力添加侧链以平衡我们的负载，因此我们的TPS没有边界。
如果我们保持Mempool不变并增加Validators的数量，则TPS增加/保持大致相似，直到Validators的数量为16并且减去后。这种行为的原因很明显。使用更多验证器，消息交换需要更多时间并达成共识。
如果我们保持Validators的数量相同并增加mempool，则TPS会增加，直到 mempool为50000并减少post。这种行 为的原因是因为，mempool越大，块中的事务数越多。块中的事务越高，每个Validator验证它们的时间就越长。
因此验证器开始超时等待来自其他验证器的投票，并且在超时之后建议新的块。
在整个负载测试期间，每个节点的CPU和内存使用率始终低于40-50%，这意味着使用较小的VM进行测试应该会获得类似的结果。
如果您想了解有关OneLedger负载测试结果的更多信息，请随时通过我们的 Telegram Dev Channel与我们联系。
