区块链性能测试设计方案分享.docx

  1. 1、本文档共13页,可阅读全部内容。
  2. 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多

??

?

??

区块链性能测试设计方案分享

?

??

?

?

?

?

?

?

?

???

?

?

?

?

?

?

?

近期区块链的技术概念在传统IT圈逐渐升温,成为许多遗产系统升级重构方案的备选技术路线。笔者本人多年从事应用系统研发,目前所维护的系统性能渐露瓶颈,分片扩容难度较大且面临分布式改进的潜在需求,因而亟需区块链架构技术储备。

应用系统性能提升的关键在于运维端的接入管理模型(AAA,认证AuthenticaTIon、授权AuthorizaTIon、计费AccounTIng)及业务端的并发(Concurrency)/吞吐量(Throughput)模型。区块链是典型的“运维友好型”系统,天然的自我治理能力极大程度上优化了接入管理模型,但现有区块链系统的并发/吞吐量模型指标却饱受诟病。无论是BTC的7tps,还是ETH的40tps在传统业务系统动辄万级甚至十万级tps面前都难以抬头。

本着不重复造轮子的宗旨,首先梳理了一下对区块链项目的需求:

·聚焦底层基础设施,项目自身行业或领域特征不明显,易引入本行业业务;

·能够实现微服务级部署,扩容友好,易迁移部署;

·并发吞吐量5k+,稳定支撑10w级DAU,可靠性强。

根据需求有的放矢地寻觅区块链项目,寻觅的过程其实远比想象的简单。区块链项目多如牛毛,但纯做技术框架不扯业务场景或者经济模型的项目真心不多。通过对主流交易所的项目筛选(毕竟不能找一个不稳定的团队做的东西),基本圈定了EOS、QTUM、AELF项目。EOS官宣吞吐量约3300~3500tps,QTUM官宣吞吐量为BTC的十倍(权且估算100tps),AELF项目7月伊始发布测试网,官方暂未发布吞吐量信息。选定AELF作为调研对象的原因一方面是开发指南新近发布,与最近代码版本的可操作性强,且AELF采用的Akka并发框架应用范围较广,先前有所接触。

测试设计

现有的区块链系统业务处理能力普遍面向价值传递进行建设,因此对于区块链系统性能的评测思路应面向交易过程展开。AELF项目在区块链架构方面主打的特征是“主链+多级侧链”,链间有专门的跨链算法实现相对隔离的业务单元间资源的协同,链内节点均运行于集群,节点内部通过并行化方案提升吞吐量指标。根据官方在社区披露的信息,测试网初期(即目前)提供主链并行计算模块的测试验证,确认主链性能后再灰度升级至多级侧链版本,从软件质量体系的角度而言是合理的。通过参与社区内的技术直播互动,也与项目技术团队充分探讨了AELF选用的几个技术方案,尤其是Akka并行框架。积极选用已被验证的成熟技术元素确实是做新系统、新基础设施时的难能可贵的姿态,进一步提升了对AELF项目的好感度。PS:该团队技术的人也在社区,很NICE很好沟通。

TransacTIon,传统IT人习惯叫“事务”,区块链圈的人通常叫“交易”,可能是BTC白皮书翻译传承下来的吧。软件测评应充分考虑软件质量体系的要求,同理,对于一个区块链底层架构而言,模拟价值传输压力的交易激励能够作为区块链底层基础设施tps指标的验证形式。

据此,先定义一个原子事务作为本次测试验证的基本测试用例——“合约转账”。1次“合约转账”包括2次读2次写操作,具体步骤如下:

·从A账户读取余额(1次读);

·从B账户读取余额(1次读);

·从A账户减去金额(1次写);

·从B账户增加金额(1次写)。

因之前接触过BTC,深深叹服中本聪大神UTXO体系设置的精妙,但传统应用系统往往还是依赖账户模型体系,因此选用一个经典的原子转账事务作为标准测试用例,并以该用例的执行效率作为吞吐量指标的依据。AELF支持区块链智能合约,上述原子事务须编写为合约脚本部署至测试网。

进而,再定义一个基本的测试流程梗概:

该测试流程可作为一个典型的区块链性能测评策略。以一次“合约转账”为一个基本业务执行单元,编写运行于区块链平台上的“合约脚本”程序,该程序能够被区块链系统各节点部署并执行。实施测评前需依据特定的用例或随机生成测试用例初始化测试数据,不同场景、不同轮次的测评实施须基于相同的测试数据以确保测试结果可信。测试数据作为交易申请相继对主网发起激励,对于AELF此类采用分布式并行化思想进行架构设计的项目,可采用多组数据并发激励的形式以测试较高并发交易场景下区块链系统的性能。测试过程中,可通过实时监视或特定时间片监视的方式判定测试用例的执行情况,时间片可设置为出块周期的N倍(N《=6,借鉴BTC主网6区块确认的惯例)。

继续定义不同的测试场景:

·场景I:单机场景,1业务处理节点+1业务数据集;

·场景II:集群-单机场景,N业务处理节点+1业务数据集;

·场景III:分布式集群场景,N业务处理节点+N业务数据集。

单机场景旨在验证区块链系统的独立性能,因区块链为分布式集群系统

文档评论(0)

姜志 + 关注
实名认证
内容提供者

搞茯苓的

1亿VIP精品文档

相关文档