一个Fabric Node客户端负载测试工具及实例分析*

高锦博 严 悍 李雪飞 周亚茹

（南京理工大学计算机科学与技术学院 南京 210094）

1 引言

性能低下是区块链的普遍问题，Hyperledger Fabric［1］亦是如此。Fabric支持通过 CLI、SDK［2］等方式来访问Fabric区块链网络［3］。其中的Fabric SDK Node［4］利用 NodeJs的异步非阻塞特点［5］作为Fabric的客户端［6］来访问Fabric网络，为应用提供服务，作为应用的服务器，它的负载能力是一个重要的关注点。负载测试［7］是通过不断增加用户请求并发数，测试不同负载条件下应用服务器对客户端请求的响应时间、吞吐率等数据，研究应用服务器所能提供的最大负载能力［8］。本文主要研究Fabric SDK Node作为Fabric网络客户端的负载测试。

文献［9］通过设计测试工具、方法，对Fabric进行测试，给出了测试数据，但并非是基于Fabric SDK Node访问网络的负载测试以及测试工具。Hyperledger Caliper是一个区块链测试工具，支持Fabric 1.1版本的测试［10］，该工具通过改变交易提交速率，进行性能测试。但是目前Fabric已经更新至1.3版本［11］，该工具的适用性还待测试。综上，目前缺乏支持Fabric 1.3，并且基于Fabric SDK Node客户端的负载测试工具。

本文针对Fabric 1.3，基于Fabric SDK Node设计一个客户端负载测试工具，通过改变并发数施加不同并发负载，并测试不同区块大小（即每个区块包含的交易数量），区块链的读写性能，分析不同区块大小、并发数和性能之间的关系。

2 方案设计

2.1 架构

测试工具以及区块链网络的架构如图1。

图1 测试工具架构图

1）在监控端通过指令调用测试工具。在调用测试工具的时候需要指定读写命令以及并发次数。

2）测试模块包含：负载发生器、数据采集、数据分析统计以及记录模块。

（1）负载发生器：根据监控端所传参数，通过NodeJS异步编程，并发执行交易请求，施加负载；

（2）数据采集：在所有交易异步并发执行的过程中，采集交易基本数据（见章节2.2），便于分析统计；

（3）数据分析统计及记录：根据采集到的交易的基本数据，计算相关性能指标（见章节2.2），如平均响应时间、吞吐率等数据；同时将所有数据记录在本地excel文件中，以便根据不同需求进行数据再次分析。

3）基础交易模块：交易模块一般分为两类，invoke写入交易和query查询交易。测试工具包含这两种交易模块的测试。

4）Fabric SDK Node：测试模块以及基础交易模块都是通过Fabric SDK Node来对Fabric区块链网络进行访问。

2.2 测试方法及度量指标

该测试工具在进行一次并发测试的过程中，对于测试并发压力的施加以及完成过程，分为三个阶段：加载期、负载期、卸载期。如图2所示。

图2 测试阶段

1）加载期：从t0到t1阶段，根据提交的参数提交n个交易，在到t1时刻加载完成最后一个交易，每个交易的起始时间都在［t0，t1］之间；

2）负载期：从t1到t2阶段，t2时刻第一个交易完成，即最快的交易完成。系统在此期间被加载所有交易，并发执行交易，但是没有一个交易完成。

3）卸载期：从t2到t3阶段，之前提交的所有交易开始陆续完成，t2时刻第一个交易完成，t3时刻最后一个交易完成，即全部交易完成。

在进行并发数为n的测试过程中，需要采集交易基本数据：

1）第i个交易的起始时间bi；

2）第i个交易的完成时间ei；

3）所有交易的起始时间t0；

4）交易加载时间t1；

5）首次交易吐出时间t2；

6）所有交易完成时间t3。

根据基本数据计算以下相关性能指标：

1）吞吐率TPS［12］（Transaction Per Second）：指从交易请求开始到所有交易完成，每秒完成的平均交易数量。

2）响应时间RT（Response Time）：指从交易提交到完成所耗费的时间，根据交易的起始时间bi和完成时间ei计算（i表示第i个交易）：

3）平均响应时间ART（AverageResponseTime）［13］：

4）交易延迟比例（Transaction Delay Ratio）：

在工具中还将分析记录最大响应时间、最小响应时间、有效交易数量和无效交易数量及比例。后续实验，主要针对吞吐率、平均响应时间、延迟比例进行分析。

2.3 实验方案

1）实验对象

测试网络由两个机构，各有两个peer节点［14］组成。

2）交易读写方式

在测试中，需要测试写入交易和查询交易的性能，交易通过单键值对的方式写入，测试过程中，设置单个键值对小于10bytes，从而尽可能测得最大写入性能。查询交易时，通过API提供的getState方法进行单键值读取。

3）软硬件环境

测试的主机硬件配置为 Intel（R）Core（TM）i7-6700 CPU@3.40GHz，内存 16GB；主机系统为ubuntu 16.04LTS；软件环境如表1。

表1 软件环境配置

表2 相关配置

表2中BatchTimeout是区块发布等待时间，MaxMessageCount是区块大小，即每个区块包含最大交易数量。Orderer是根据配置中的BatchTimeout以及MaxMessageCount将交易分成区块。当交易数量达到MaxMessageCount的时候，Orderer节点将交易打包成区块，或者当交易数量不足MaxMessageCount时，若时间超过BatchTimeout，则将这些交易打包成区块。

在利用Farbric SDK Node写入交易时，设置交易延迟等待为45s。

4）实验过程

交易写入测试中，区块大小（即MaxMessage-Cout）的值以及并发数设置如表3。

表3 交易写入时区块大小和并发数设置

交易查询测试中，并发数设置为：10、100、500、1000、2000、…、7000…。

对于同一并发数，进行50次测试，计算平均值。

3 实验结果分析

3.1 写入交易测试

整理分析实验数据，不同区块大小时，吞吐率随并发数的变化结果如图3。

对于同一区块大小，吞吐率随着并发数的增加，先递增然后下降。这是因为随着并发数的增加，交易产生延迟。当其中一个交易产生延迟，响应时间增加，从而导致TPS下降。同时随着并发数的增加，交易延迟的比例也越来越高。如图4，对于任一区块大小，随着并发数从200增加到300、400，交易延迟比例增加，同时平均响应时间相应增加，如图5。

图3 交易写入的吞吐率

图4 交易写入的延迟比例

图5 交易写入的平均响应时间

吞吐率的峰值会随着区块大小的增加而增加。当区块大小从10提高到20时，最大TPS从75提升到102.6，提升了36.8%，当每个区块交易数从10提高到50的时候，TPS从75提高到了117.6，提升了56.8%。但是当区块大小继续增大，峰值TPS下降，如当区块大小为100的时候的最大TPS小于区块大小为50的最大TPS。

当交易并发数小于50的时候，区块大小较小时，吞吐率高，区块大小设置为50的吞吐率小于区块大小为10以及20，但高于区块大小为100的时候的吞吐率。

当交易并发数大于200的时候，区块大小为100的时候，吞吐率高于其它区块大小的吞吐率。在测试过程中，同样在并发数据为300时，区块大小为100的时候，交易延迟比例小于其他三个区块大小的延迟比例。

3.2 查询交易测试

对于交易查询进行测试，吞吐率测试结果如图6。

图6 交易查询的吞吐率

对于同一区块大小，交易查询的吞吐率均随着并发数的增加先递增，然后下降，如图6，最大吞吐率稳定在625，并且不同的区块大小对交易查询的吞吐率无显著影响，不同区块大小的吞吐率曲线基本重合。

图7 交易查询的平均响应时间

对于交易查询的平均响应时间如图7，随着并发数的增加，平均响应时间线性增加，同时交易的查询平均响应时间基本不受区块大小的影响。

4 分析与比较

相比较Caliper和其他研究，该测试工具具有以下特点。

1）适应Fabric 1.3版本：基于Fabric SDK Node开发，适用于通过该SDK开发的应用测试，支持Fabric 1.3版本。

2）非延迟的负载施加方式：该工具通过改变不同的并发数，并以客户端最大速率来施加不同负载，而Caliper通过改变交易请求速率施加负载。

3）客户端测试：该工具是基于客户端测试，测试通过Fabric SDK Node访问Fabric网络的负载能力，而不同于其他研究中的服务器端测试［16］。

4）可扩展性：测试工具中采集了基本数据，如每个交易的起止时间，响应时间等数据，同时又能通过基本数据分析统计其它数据，如延迟交易比例、吞吐率、平均响应时间、最大或者最小响应时间等。同时将所有采集到的数据记录在本地文件中，可以进行二次分析。

5 结语

本文介绍了一种基于Fabric SDK Node，适应Fabric 1.3版本的客户端负载测试工具。该工具通过改变并发数施加不同负载，进行负载测试，同时可以采集多种数据进行本地记录，进行再次分析，具有较好的扩展性。同时使用该工具针对Fabric 1.3版本，测试不同区块大小时，通过Fabric SDK Node访问网络，peer对Fabric的读写性能。通过测试，写入交易时，对于并发数较低的情况设置较小区块大小比较合适，对于较高并发数的情况建议设置较大区块大小，但同时，区块越大，峰值的TPS会降低；在查询交易时，区块大小对查询性能基本不产生影响。在以后的研究中，还将继续完善该测试工具，并从更多的角度去测试区块链的性能，研究区块链性能的影响因素；也将进一步对多键值写入和查询进行负载测试。