[BMT] EOSIO TPS第二次测试结果 by EOSeoul -验证Block One测试及JIT使用测试

eoseoul (52)in #cn • 6 years ago (edited)

4月24日 EOSeoul报告TPS和4月26日 BlockOne实验室环境测试

EOSeoul在4月24日给Block One发送了EOSeoul的BMT TPS结果和问题。

https://steemit.com/en/@eoseoul/bmt-eosio-tps-results-by-eoseoul

然后Block One通过邮件、Steemit、Telegram分享了他们得到TPS数据的方法。

Instructions : https://gist.github.com/spoonincode/fca5658326837b76fd744d39b2a25b4e
github issue : https://github.com/EOSIO/eos/issues/2078

Block One的测试方式是在一个物理系统上使用一个BP node和一个Full node之间的binaryen Interpreter的测试方式。简单来说Block One的TPS测试方式是单纯测试EOS引擎性能的"实验室环境测试"。Block One的测试设置是排除了实际环境中可能会导致性能下降的各种因素，只把通过P2P接受Transaction、制造区块、Broadcast区块的一系列核心性能换算为TPS值。所以Block One的测试环境可以说是更接近于汽车的理论油耗测试方式。

EOSeoul的TPS测试方式和Block One的实验室TPS测试方式不同。EOSeoul做为主网上线前的模拟测试，把测试环境设置为当下很多BP候选人作为测试网的云环境和EOS设置。现在大部分的BP node已经激活了HTTP plugin并接受Transaction。EOSeoul也在同样的环境下进行了测试，并为了确认EOS系统的崩溃上限发送了足够的query。即，包括实际服务环境中可能导致性能下降的"压力基准"。由于EOSeoul的报告是看主网实际运行的，所以得到的结果会比实验室测试结果要低。可以说EOSeoul的测试方式是接近于汽车的实际油耗测试方式。

Block One测试验证和重新测试

EOSeoul通过Block One的实验室测试方式确认了在intel i7-6700 3.4GHz CPU环境下1200+ TPS的处理量。并确认了在同样的CPU环境下激活JIT可以得到2000+ TPS的处理量。接下来看一下在云环境下通过和Block One一样的方式进行测试会得到怎样的结果。

在云环境下验证Block One的测试方式

Test环境信息

Build : DAWN-v3.0.0 (d9ad8eec)
AWS EC2 m5.2xlarge
- CPU : Intel Xeon Platinum 8175M 2.5Ghz * 8 Core
- Mem : 32G
- Disk : EBS 120GB SSD (3000 IOPS Fix)
AWS EC2 C5.2xlarge
- CPU : Intel Xeon Platinum 8124M 3.0Ghz * 8 Core
- Mem : 16G
- Disk : EBS 120GB SSD (3000 IOPS Fix)

测试说明

txn_test_gen设置
- 发生周期(ms) x Transaction数(count per interval)
- 20x20 : 每20ms产生20Transaction
- 50x60 : 每50ms产生60Transaction

基准1. M5.2xlarge - EC2 1 : FN 1 + PN 1

20x20 (1000TPS) : 可以确认1000 TPS。但是，在一定时间之后有Transaction处理量延迟迹象。有点不稳定。 BP node CPU : 42%, Full node CPU : 82%
22x20 (约900TPS) : 还算稳定。BP node : 35%, Full node : 78%左右
50x60 (1200TPS) : 在进行处理中CPU达到100%并中断，不能处理。
60X58 (966TPS) : 在做处理之后会变不稳定。但是处理量会达到966 TPS。BP node : 40%, Full node : 79%

基准2. C5.2xlarge - EC2 1 : FN 1 + PN 1

20x20 : 可以稳定处理1000 TPS。BP node CPU 30% , Full node 65%左右
20x22 : 可以稳定处理1100 TPS。BP node CPU 34~35%, Full node 75%左右
20x24 : 还算可以稳定处理1200 TPS。BP node CPU 38%, Full node 80%左右
20x26 : 1300 TPS没有处理量，性能下降到大约能够处理1000 TPS。BP Ndoe CPU : 43%, Full node : 83%
50x60 : 1200 TPS和上面一样
50x66 : 有1320 TPS算正常，但是没有正常的TPS结果。

基准3. C5 EC2 2台 : FN1 + PN1

20x20 : 可以稳定处理1000TPS。BP node CPU 30% , Full node 60% 左右
20x22 : 可以稳定处理1100TPS。BP node CPU 36%, Full node 70% 左右
20x24 : 还算可以稳定处理1200TPS，但是有一点延迟迹象。BP node CPU 38%, Full node 78~80%
20x26 : 可以稳定处理1300TPS，看似比1200 TPS还要稳定。BP node 42%, Full node 82~84%
20x28 : 有1400TPS算正常，但实际展现出1000 TPS左右的处理量。CPU使用量也不稳定。

基准4. C5 EC2 3台 : FN2 + PN1

20x20 : 可以稳定处理1000TPS。BP node 33~38% , Full node1 58~64%, Full node2 52~56%
20x22 : 可以稳定处理1100TPS。BP node 38~40%, Full node1 68~72%, Full node2 58~64%
20x24 : 可以稳定处理1200TPS。BP node 40~42%, Full node1 74~80%, Full node2 60~70%
20x26 : 没有正常的1300TPS处理量，约1000~1100 TPS左右性能。BP, Full node的CPU使用量都不稳定。不清楚是不是Block处理量延迟，瞬间处理量达到966，但之后的Block才达到99左右。低处理量时CPU使用量也随之降低。
20x28 : 1400 TPS不能处理。报错之后停止BMT。
20x12x2 : 可以稳定处理600+600 TPS。因为是2个node一起产生600TPS左右，所有不知道是因为Broadcast时间还是网络传递时间问题，有一些延迟迹象，但是能够稳定处理。BP node : 40~44%, Full node1 : 68~74%, Full node2 : 76~80%, Full node2的CPU稍微更高。
20x14x2 : 700+700TPS瞬间达到1400，但是由于2个node中有一个发生报错停止BMT。可能是CPU不能分配的问题报错而导致实验停止。BP node 58~64%, Full node : 最高98%以上, 因为是报错而停止测试，所以CPU使用量没有意义。
20x20+20x6 : 在1000 + 300 TPS测试中也不稳定，属于300 TPS的TEST Job被停止。CPU和第七个环境相同

在云环境激活JIT并验证Block One测试方式

基准5. C5 EC2 2台 : FN1 + PN1 (Using WAVM ~ JIT)

20x20(1000 TPS) : 很稳定. CPU使用量也是 BP node 30~34%, Full node 33~37%左右
20x30(1500 TPS) : 很稳定的能够确认1500 TPS。BP node 50%, Full node 55%左右
20x36(1800 TPS) : 确认稳定的1800 TPS。BP node 56~60%, Full node 66~70%左右
20x38(1900 TPS) : 确认稳定的1900 TPS。BP node 58~62%, Full node 68~72%左右
20x40(2000 TPS) : 一开始就失败。应该是处理量超限导致。需要在CPU Clock更高的服务器进行测试或需要优化。

回顾结果

可以确认在Dawn 3.0文件中Dan Larimer(BM)提出的1000 TPS(Worst case)。但这是对引擎的性能测试，可以推测和实际环境下的性能会有所差异。
通过基准1和2的结果可以确认在主网上线初期使用CPU性能高的服务器是最理想的。
分离Full node和BP node时有性能提高现象。Full node和BP node确实需要被分离。但也不会对性能有很大的影响。
合理的主网压力测试需要分离BP node和Full node进行。从性能等多方面因素去考虑，BP node还起到Full node作用的现今TESTNET架构可以说是不适合的架构。
确认了随着Full node增加会导致性能降低现象。以1300 TPS为准，在Full node 1个 BP node 1个结构中可以得到稳定的结果，但在Full node 2个 BP node 1个的结构下实际测出的TPS才1300以下，有不稳定的结果。
可以预计BP node增加也会导致性能降低。BP node间的通讯所占有资源的现象可以导致整个系统性能降低。
推测是在传输BP node和Full node处理的Block和Transaction到其他node时发生性能降低现象。所以可以预计node数越多性能会越低。
激活JIT可以提高性能。和Dawn 3.0文件中描述的一样，在首次发布的contract使用binaryen，同时在后台使用JIT的话可以期待更理想的性能。

感谢之词

在EOSeoul分享EOSIO测试基准报告之后得到了很多热烈的反馈，非常感谢给我们反馈的所有的朋友。

首先感谢Daniel Larimer和Block One开发人员。如果4月24日的基准报告让各位不开心的话在这里表示歉意。EOSeoul的意图是想确认在一般服务环境中的EOSIO性能。在压力测试的角度觉得txn_test_gen plugin的构成有些简单，并假设了Block One在更复杂的基准环境下得到4月6日Dawn 3.0文件的性能结果。我们通过github log看到了通过各位的努力EOSIO在迅速发展。我们再次非常感谢各位给EOSeoul的亲切回答及专业的反馈。

同时也非常感谢包括EOS Cannon在内的给出各种反馈的BP候选人及开发人员。各位的评论可以帮助EOSeoul进行更客观信赖的测试。特别想提到的是，EOS Cannon把自己的Block One实验室测试结果分享给我们，在这里再次感谢展现合作精神的EOS Cannon。希望我们能够分享有意义的结果并专注于稳定的主网上线。