由于微信限制了第三方应用的跳转,请使用以下方法。
1. 点击右上角的
2. 选择在浏览器中打开
由于微信限制了第三方应用的跳转,请使用以下方法。
1. 点击右上角的
2. 选择在浏览器中打开
作者：袁煜明 胡智威
摘要
火币区块链应用研究院对EOSIO的Dawn 3.0版本在测试环境中通过多个场景的测试对比进行了平台性能的研究分析。
基于测试条件下（局域网环境内的AWS服务器）的EOSIO最大能达到1900 TPS。这与Dawn 3.0说明文档中的平均TPS（3000）、最优TPS（6000）和理论最优TPS（8000）仍有差距，但可稳定达到文档所述最差情况下1000 TPS
随着服务器配置的提升，系统最大TPS会随之提高。同时，在条件允许的情况下，增加超级节点（Block Producer）的服务器资源，可得到更好的整体性能。因此在主网环境下，建议为节点使用尽可能高配置的服务器
去中心化部署会对性能有不利影响。由于目前EOSIO的程序代码还不支持多线程，因此只能使用单核CPU，暂时无法利用并行计算提高效率。在此情况下，去中心化的部署尤其是增加超级节点并不会因分摊单个服务器压力而提高性能，反而会增加CPU开销，并可能对TPS产生影响
合理使用JIT会有一定性能提升。该方式可降低CPU使用率并提高一定程度的TPS，但需注意对稳定性的影响
目录
报告正文
1. 引言
目前EOS超级节点竞选活动仍在如火如荼的进行当中。据统计，截止5月2日，目前活跃的竞选组织有102个。与此同时，block.one在4月份发布了EOSIO的Dawn 3.0版本，并计划于6月份上线主网。
此前众多社区已组建了测试网络，并对EOSIO性能尤其是每秒能处理交易数量（TPS）进行了测试。但TPS性能受制于编译参数、服务器硬件、操作系统、网络等诸多条件，测试出来的结果更多的是实验室条件下的“理论油耗”（参考 https://steemit.com/cn/@eoseoul/bmt-eosio-tps-by-eoseoul-block-one-jit）。
因此与此前的很多测试不同，火币区块链应用研究院本次的研究分析并不是围绕EOSIO是否能达到Dan Larimer团队所宣称的1M TPS展开，而是通过分析Dawn3.0在不同条件下观测到的性能指标，对未来主网架构及服务器配置等提出思路与建议。后续如果有新版本例如Dawn4.0等，火币区块链应用研究院会继续跟进研究。
另外需要注意的是：测试得到的指标数据结果不是也不应被视为是对EOSIO平台或项目最终效果的证明或确认。特此声明。
2. 主要结论
经过测试结果与分析研究，我们得到以下主要结论及技术建议：
l 基于我们测试条件下（局域网环境内的AWS服务器）的EOSIO最大能达到1900 TPS，与Dawn 3.0说明文档（参考https://medium.com/eosio/eosio-dawn-3-0-now-available-49a3b99242d7）中的平均TPS（3000）、最优TPS（6000）和理论最优TPS（8000）仍有差距，但可稳定达到文档所述最差情况下1000 TPS
l 随着服务器配置的提升，系统最大TPS会随之提高。同时，在条件允许的情况下，增加超级节点（Block Producer）的服务器资源，可得到更好的整体性能。因此在主网环境下，建议为节点使用尽可能高配置的服务器
l 由于目前EOSIO的程序代码还不支持多线程，因此只能使用单核CPU，暂时无法利用并行计算提高效率。在此情况下，去中心化的部署尤其是增加超级节点并不会因分摊单个服务器压力而提高性能，反而会增加CPU开销，并可能对TPS产生影响
l 合理使用JIT可降低CPU使用率并提高一定程度的TPS，但需注意对稳定性的影响
3. 测试条件说明
3.1 测试程序版本
测试程序为EOSIO的dawn-v3.0.0版本
3.2 测试硬件环境
亚马逊AWS，型号按照配置高低主要有以下两种：
AWS EC2 t2.large（下文简称低配服务器）: 2 核 2.3 GHz, Intel Broadwell E5-2686v4 CPU, 8GB内存
AWS EC2 C5.4xlarge（下文简称高配服务器）: 16 核 3GHz, Intel Xeon Platinum 8124M CPU，32GB内存
服务器间为10Gbps局域网网络，通讯延迟（ping）小于1ms
操作系统为Ubuntu 16.04
3.3 测试方法及工具
使用block.one提供的txn_test_gen测试插件工具发送测试交易数据并观察实际TPS与系统CPU使用率等指标情况。（参考https://github.com/EOSIO/eos/wiki/Testnet-Single-Host-Multinode与https://gist.github.com/spoonincode/fca5658326837b76fd744d39b2a25b4e）
4. 具体测试场景及结果分析
4.1 场景1
将1个“超级节点”（Block Producer，以下简称BP）和1个普通节点（Full Node，以下简称FN）部署在同一台低配服务器上。
通过连接FN发送测试数据的结果如下：
表4.1a：BP和FN在同一台低配服务器上的测试结果（通过FN发请求）
报单速率（TPS） | BP（CPU使用率） | FN（CPU使用率） | 实际处理速率（TPS） |
1000 | 45% | 93% | 1000 |
1100 | 49% | 99% | 1100 |
1200 | 49% | 100% | 1104左右 |
通过连接BP发送测试数据的结果如下：
表4.1b：BP和FN在同一台低配服务器上的测试结果（通过BP发请求）
报单速率（TPS） | BP（CPU使用率） | FN（CPU使用率） | 实际处理速率（TPS） |
1000 | 58% | 68% | 1000 |
1100 | 65% | 77% | 1100 |
1200 | 71% | 83% | 1200 |
1300 | 77% | 94% | 1300 |
1400 | 83% | 98% | 1400 |
1500 | 91% | 100% | 1500 |
1600 | 93%-95% | 100% | 1600 |
1700 | 100% | 40%-100% | 1700 |
值得注意的是，当报单速率为1700时，虽然BP的CPU已100%使用，但BP可稳定处理；同时FN进程所在CPU的使用率起伏较大，无法及时从BP同步到区块，并且随着系统运行，BP与FN之间的区块高度差距会越拉越大。
通过该场景的结果可发现：
由于目前EOSIO的程序还不支持多线程，因此暂时无法利用多核CPU的并行计算提高效率；
BP的CPU使用率低于FN，似乎与通常对“超级节点”的认识相反。这原因可能是因为上述两种节点所承担的工作不同：BP设计理念是为了保证交易安全性和完整性（不丢失区块），而FN被设计为对外提供服务，需要进行交易签名、序列化、验证等等；
报单分别通过BP和FN发送时，平台TPS有显著差异，这也与上述需要处理交易的签名、序列化等工作有关。
4.2 场景2
提高服务器配置，继续观察系统性能。将1个Block Producer（以下简称BP）和1个Full Node（以下简称FN）部署在同一台高配服务器上。
通过连接FN发送测试数据的结果如下：
表4.2a：BP和FN在同一台高配服务器上的测试结果（通过FN发请求）
报单速率（TPS） | BP（CPU使用率） | FN（CPU使用率） | 实际处理速率（TPS） |
1000 | 28% | 59% | 1000 |
1100 | 32% | 66% | 1100 |
1200 | 35% | 72% | 1200 |
1300 | 38% | 78% | 1300 |
1400 | 启动后很快中断 |
通过连接BP发送测试数据的结果如下：
表4.2b：BP和FN在同一台高配服务器上的测试结果（通过BP发请求）
报单速率（TPS） | BP（CPU使用率） | FN（CPU使用率） | 实际处理速率（TPS） |
1000 | 42% | 47% | 1000 |
1100 | 46% | 52% | 1100 |
1200 | 51% | 56% | 1200 |
1300 | 55% | 61% | 1300 |
1400 | 60% | 66% | 1400 |
1500 | 63% | 70% | 1500 |
1600 | 67% | 73% | 1600 |
1700 | 71% | 78% | 1700 |
1800 | 76% | 82% | 1800 |
1900 | 80% | 86% | 1900 |
2000 | 启动后很快中断 |
对比场景1可看到，随着服务器配置的提升，系统最大TPS会随之提高。
4.3 场景3
以上场景是将BP和FN部署在同一台服务器上，而本场景是将BP和FN分别部署在两台高配服务器上。
通过连接FN发送测试数据的结果如下：
表4.3a：BP和FN分别在两台高配服务器上的测试结果（通过FN发请求）
报单速率（TPS） | BP（CPU使用率） | FN（CPU使用率） | 实际处理速率（TPS） |
1000 | 32% | 65% | 1000 |
1100 | 35% | 73% | 1100 |
1200 | 37% | 78% | 1200 |
1300 | 45% | 82% | 1300 |
1400 | 启动后很快中断 |
通过连接BP发送测试数据的结果如下：
表4.3b：BP和FN分别在两台高配服务器上的测试结果（通过BP发请求）
报单速率（TPS） | BP（CPU使用率） | FN（CPU使用率） | 实际处理速率（TPS） |
1000 | 44% | 52% | 1000 |
1100 | 49% | 58% | 1100 |
1200 | 54% | 63% | 1200 |
1300 | 58% | 68% | 1300 |
1400 | 63% | 73% | 1400 |
1500 | 67% | 77% | 1500 |
1600 | 71% | 81% | 1600 |
1700 | 76% | 89% | 1700 |
1800 | 81% | 91% | 1800 |
1900 | 86% | 94% | 1900 |
2000 | 启动后很快中断 |
对比场景2可看到，本场景中的CPU使用率与同条件相比略微提高，应为处理网络通讯的开销；分别部署并未显著影响TPS，这也与目前单线程方式有关：BP和FN部署在同一台服务器上并不会争夺CPU资源，因此在当前代码未支持多线程的情况下分开部署有可能并不会因分摊压力而提高性能，反而略微增加了CPU开销。
4.4 场景4
以上场景是将BP和FN分别部署在同一配置服务器上，而场景4与场景5是将BP和FN分别部署在不同配置的服务器上。本场景是BP部署在低配服务器上，FN部署在高配服务器上
通过连接FN发送测试数据的结果如下：
表4.4a：BP在低配服务器、FN在高配服务器上的测试结果（通过FN发请求）
报单速率（TPS） | BP（CPU使用率） | FN（CPU使用率） | 实际处理速率（TPS） |
1000 | 42% | 68% | 1000 |
1100 | 47% | 76% | 1100 |
1200 | 53% | 81% | 1058左右 |
通过连接BP发送测试数据的结果如下：
表4.4b：BP在低配服务器、FN在高配服务器上的测试结果（通过BP发请求）
报单速率（TPS） | BP（CPU使用率） | FN（CPU使用率） | 实际处理速率（TPS） |
1000 | 57% | 54% | 1000 |
1100 | 64% | 60% | 1100 |
1200 | 68% | 65% | 1200 |
1300 | 72%-75% | 70% | 1300 |
1400 | 78%-81% | 76% | 1400 |
1500 | 83%-88% | 78% | 1500 |
1600 | 90%-95% | 83% | 1600 |
1700 | 100% | 87%-91% | 1700 |
1800 | 无法启动 |
4.5 场景5
本场景是BP部署在高配服务器上，FN部署在低配服务器上。
通过连接FN发送测试数据的结果如下：
表4.5a：BP在高配服务器、FN在低配服务器上的测试结果（通过FN发请求）
报单速率（TPS） | BP（CPU使用率） | FN（CPU使用率） | 实际处理速率（TPS） |
1000 | 29% | 80%-82% | 1000 |
1100 | 31% | 85%-88% | 1100 |
1200 | 34% | 100% | 1200 |
通过连接BP发送测试数据的结果如下：
表4.5b：BP在高配服务器、FN在低配服务器上的测试结果（通过BP发请求）
报单速率（TPS） | BP（CPU使用率） | FN（CPU使用率） | 实际处理速率（TPS） |
1000 | 40% | 64% | 1000 |
1100 | 45% | 71% | 1100 |
1200 | 50% | 77%-79% | 1200 |
1300 | 53% | 83%-86% | 1300 |
1400 | 58% | 90% | 1400 |
1500 | 62% | 92%-96% | 1500 |
1600 | 65% | 100% | 1600 |
1700 | 70% | 100% | 1700 |
1800 | 无法启动 |
对比场景4和场景5，在条件允许的情况下，为BP分配更多的资源，可得到更好的整体性能
4.6 场景6
以上场景是两台服务器的情况（1个BP、1个FN）。增加1个FN后，本场景为1个BP、2个FN分别部署在3台高配服务器上。
通过连接FN发送测试数据的结果如下：
表4.6a：1个 BP、2个FN分别在3台高配服务器上的测试结果（通过FN发请求）
报单速率 | BP | FN（发送端） | FN | 实际处理速率 |
1000 | 37% | 66% | 53% | 1000 |
1100 | 41% | 73% | 58% | 1100 |
1200 | 44% | 80% | 64% | 1200 |
1300 | 50% | 84% | 80% | 1064左右 |
1400 | 启动后很快中断 |
通过连接BP发送测试数据的结果如下：
表4.6b：1个 BP、2个FN分别在3台高配服务器上的测试结果（通过BP发请求）
报单速率 | BP | FN | FN | 实际处理速率 |
1000 | 46% | 52% | 53% | 1000 |
1100 | 50% | 56% | 58% | 1100 |
1200 | 55% | 61% | 63% | 1200 |
1300 | 59% | 65% | 67% | 1300 |
1400 | 64% | 71% | 73% | 1400 |
1500 | 67% | 74% | 76% | 1500 |
1600 | 72% | 79% | 81% | 1600 |
1700 | 77% | 83% | 86% | 1700 |
1800 | 82% | 88% | 90% | 1800 |
1900 | 86% | 90%-92% | 94% | 1900 |
2000 | 启动后很快中断 |
对比场景2的结果可看到，在单线程情况下增加服务器会提高CPU开销，并可能对TPS产生影响。
4.7 场景7
以上场景是单个BP的情况。我们在本场景中增加节点为2个BP和2个FN并观察结果。
通过连接FN发送测试数据的结果如下：
表4.7a：2个 BP、2个FN分别在4台高配服务器上的测试结果（通过FN发请求）
报单速率 | BP（CPU使用率） | BP（CPU使用率） | FN（发送端） | FN（CPU使用率） | 实际处理速率 |
1000 | 38%-62% | 48%-74% | 73%-77% | 67%-71% | 1000 |
1100 | 启动后很快中断 |
通过连接BP发送测试数据的结果如下：
表4.7b：2个 BP、2个FN分别在4台高配服务器上的测试结果（通过BP发请求）
报单速率 | BP（发送端） | BP（CPU使用率） | FN（CPU使用率） | FN（CPU使用率） | 实际处理速率 |
1000 | 45%-63% | 43%-64% | 60%-64% | 60%-64% | 1000 |
1100 | 50%-74% | 49%-76% | 70%-74% | 70%-76% | 1100 |
1200 | 启动后很快中断 |
对比场景6可看到，同等情况下的CPU使用率会增高，同时所能达到的最大TPS也有较大幅度的降低，表明增加BP会对性能有较大影响。如果在多节点分布在异地的主网环境中，还会叠加网络延迟等更为复杂的环境因素。这对节点服务器资源提出更高要求。
4.8 场景8
另外，在Dawn 3.0描述文件中提到了本版本的默认解释器从JIT改为了Binaryen WebAssembly，这会降低性能但带来稳定性的提高并降低编译智能合约时的延迟。我们对场景2的运行参数改为JIT并观察结果。
通过连接FN发送测试数据的结果如下：
表4.8a：BP和FN在同一台高配服务器上并启用JIT的测试结果（通过FN发请求）
报单速率（TPS） | BP（CPU使用率） | FN（CPU使用率） | 实际处理速率（TPS） |
1000 | 16% | 33% | 1000 |
1100 | 18% | 37% | 1100 |
1200 | 19% | 40% | 1200 |
1300 | 21% | 43% | 1300 |
1400 | 23% | 47% | 1400 |
1500 | 24% | 50% | 1500 |
1600 | 26% | 54% | 1600 |
1700 | 28% | 58% | 1700 |
1800 | 29% | 61% | 1800 |
1900 | 启动后很快中断 |
通过连接BP发送测试数据的结果如下：
表4.8b：BP和FN在同一台高配服务器上并启用JIT的测试结果（通过BP发请求）
报单速率（TPS） | BP（CPU使用率） | FN（CPU使用率） | 实际处理速率（TPS） |
1000 | 31% | 24% | 1000 |
1100 | 34% | 26% | 1100 |
1200 | 37% | 29% | 1200 |
1300 | 40% | 31% | 1300 |
1400 | 43% | 33% | 1400 |
1500 | 46% | 35% | 1500 |
1600 | 49% | 38% | 1600 |
1700 | 52% | 42% | 1700 |
1800 | 56% | 43% | 1800 |
1900 | 59% | 45% | 1900 |
2000 | 启动后很快中断 |
对比场景2可看到，CPU使用率大幅度降低，但在CPU并未完全使用的情况下发生测试中断，证明JIT确实会影响系统稳定性
火币区块链应用研究院
关于我们：
火币区块链应用研究院（简称“火币研究院”）成立于2016年4月，于2018年3月起全面拓展区块链各领域的研究与探索，主要研究内容包括区块链领域的技术研究、行业分析、应用创新、模式探索等。我们希望搭建涵盖区块链完整产业链的研究平台，为区块链产业人士提供坚实的理论基础与趋势判断，推动整个区块链行业的发展。
联系我们：
咨询邮箱： | huobiresearch@huobi.com |
简书公众号： | 火币区块链研究院 |
Twitter: | Huobi_Research |
https://twitter.com/Huobi_Research | |
Medium: | Huobi Research |
https://medium.com/@huobiresearch | |
Facebook: | Huobi Research |
https://www.facebook.com/Huobi-Research-655657764773922 | |
Website: | http://research.huobi.com/ |
免责声明：
1. 火币区块链研究院与本报告中所涉及的数字资产或其他第三方不存在任何影响报告客观性、独立性、公正性的关联关系。
2. 本报告所引用的资料及数据均来自合规渠道，资料及数据的出处皆被火币区块链研究院认为可靠，且已对其真实性、准确性及完整性进行了必要的核查，但火币区块链研究院不对其真实性、准确性或完整性做出任何保证。
3. 报告的内容仅供参考，报告中的事实和观点不构成相关数字资产的任何投资建议。火币区块链研究院不对因使用本报告内容而导致的损失承担任何责任，除非法律法规有明确规定。读者不应仅依据本报告作出投资决策，也不应依据本报告丧失独立判断的能力。
4. 本报告所载资料、意见及推测仅反映研究人员于定稿本报告当日的判断，未来基于行业变化和数据信息的更新，存在观点与判断更新的可能性。
5. 本报告版权仅为火币区块链研究院所有，如需引用本报告内容，请注明出处。如需大幅引用请事先告知，并在允许的范围内使用。在任何情况下不得对本报告进行任何有悖原意的引用、删节和修改。
来源：
发布人：袁煜明
声明：该文观点仅代表作者本人，不代表火讯财经立场。火讯财经系信息发布平台，仅提供信息存储空间服务。
如文章涉及侵权， 请及时致函告之，本站将第⼀时间删除⽂章。邮箱：840034348@qq.com
