火币区块链应用研究院对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，但需注意对稳定性的影响。
目前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平台或项目最终效果的证明或确认。特此声明。
经过测试结果与分析研究，我们得到以下主要结论及技术建议：
基于我们测试条件下（局域网环境内的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。
随着服务器配置的提升，系统最大TPS会随之提高。同时，在条件允许的情况下，增加超级节点（Block Producer）的服务器资源，可得到更好的整体性能。因此在主网环境下，建议为节点使用尽可能高配置的服务器。
由于目前EOSIO的程序代码还不支持多线程，因此只能使用单核CPU，暂时无法利用并行计算提高效率。在此情况下，去中心化的部署尤其是增加超级节点并不会因分摊单个服务器压力而提高性能，反而会增加CPU开销，并可能对TPS产生影响。
合理使用JIT可降低CPU使用率并提高一定程度的TPS，但需注意对稳定性的影响。
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.1 场景1
将1个“超级节点”（Block Producer，以下简称BP）和1个普通节点（Full Node，以下简称FN）部署在同一台低配服务器上。
通过连接FN发送测试数据的结果如下：
通过连接BP发送测试数据的结果如下：
值得注意的是，当报单速率为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发送测试数据的结果如下：
通过连接BP发送测试数据的结果如下：
对比场景1可看到，随着服务器配置的提升，系统最大TPS会随之提高。
4.3 场景3
以上场景是将BP和FN部署在同一台服务器上，而本场景是将BP和FN分别部署在两台高配服务器上。
通过连接FN发送测试数据的结果如下：
通过连接BP发送测试数据的结果如下：
对比场景2可看到，本场景中的CPU使用率与同条件相比略微提高，应为处理网络通讯的开销；分别部署并未显著影响TPS，这也与目前单线程方式有关：BP和FN部署在同一台服务器上并不会争夺CPU资源，因此在当前代码未支持多线程的情况下分开部署有可能并不会因分摊压力而提高性能，反而略微增加了CPU开销。
4.4 场景4
以上场景是将BP和FN分别部署在同一配置服务器上，而场景4与场景5是将BP和FN分别部署在不同配置的服务器上。本场景是BP部署在低配服务器上，FN部署在高配服务器上
通过连接FN发送测试数据的结果如下：
通过连接BP发送测试数据的结果如下：
4.5 场景5
本场景是BP部署在高配服务器上，FN部署在低配服务器上。
通过连接FN发送测试数据的结果如下：
通过连接BP发送测试数据的结果如下：
对比场景4和场景5，在条件允许的情况下，为BP分配更多的资源，可得到更好的整体性能。
4.6 场景6
以上场景是两台服务器的情况（1个BP、1个FN）。增加1个FN后，本场景为1个BP、2个FN分别部署在3台高配服务器上。
通过连接FN发送测试数据的结果如下：
通过连接BP发送测试数据的结果如下：
对比场景2的结果可看到，在单线程情况下增加服务器会提高CPU开销，并可能对TPS产生影响。
4.7 场景7
以上场景是单个BP的情况。我们在本场景中增加节点为2个BP和2个FN并观察结果。
通过连接FN发送测试数据的结果如下：
通过连接BP发送测试数据的结果如下：
对比场景6可看到，同等情况下的CPU使用率会增高，同时所能达到的最大TPS也有较大幅度的降低，表明增加BP会对性能有较大影响。如果在多节点分布在异地的主网环境中，还会叠加网络延迟等更为复杂的环境因素。这对节点服务器资源提出更高要求。
4.8 场景8
另外，在Dawn 3.0描述文件中提到了本版本的默认解释器从JIT改为了Binaryen WebAssembly，这会降低性能但带来稳定性的提高并降低编译智能合约时的延迟。我们对场景2的运行参数改为JIT并观察结果。
通过连接FN发送测试数据的结果如下：
通过连接BP发送测试数据的结果如下：
对比场景2可看到，CPU使用率大幅度降低，但在CPU并未完全使用的情况下发生测试中断，证明JIT确实会影响系统稳定性
