测试背景

本次对本体的性能测试，代码全部来自本体GitHub开源代码，此版本没有加入并行处理和分片。所用的硬件环境是普通的云服务节点。

本次测试是在VBFT共识下，7共识节点的单链测试，不包含并行处理、分片 和 FPGA硬件加速 等官方还未开源的优化点。

TPS（Transaction per Second）每秒交易处理笔数，反映了系统在同一时间内能处理业务的最大能力，是区块链的核心性能指标之一。Apache JMeter是Apache组织开发的基于Java的压力测试工具， 本文使用JMeter对Ontology 0.8.2 版本做压测，将测试过程及结果记录如下。相关测试工具及使用方法见：https://github.com/qiluge/VBFT_TPS_TEST

测试小结

没有加入分片、并行处理 和 FPGA硬件加速 的前提下，本次共进行了10次测试，取10次结果的平均值，最终结果如下。此测试结果在公链中处于较高水准。

交易数：300万 发送速率：6000/s 发送时间：500s 落账成功率：99.1% 块数：40 处理时间：562s TPS：5341 峰值：5536

注1：TPS = 成功交易数/（完成落账时间 - 开始发送交易时间）

注2：峰值 即是 系统稳定运行 所能达到的最大TPS，算法为 取落账过程中 中间时段的 一到两分钟之内的落账笔数，除以落账时间。

一、测试环境

每个节点为微软云虚拟机，共7个共识节点，硬件配置如下：

CPU：单节点 8核 CPU，具体信息如下：

名称：Intel(R) Xeon(R) CPU E5-2673 v3 主频：2.40GHz 缓存大小：30720 KB 核数：8

内存：单节点27G

硬盘：固态硬盘，大小50G，读写速率限制不超过25MB/s

软件配置如下：

系统信息：ubuntu 16.04.4 LTS

Go环境：go1.9.3 linux/amd64

二、Ontology参数

Ontology版本为0.8.2，启动命令为：

./ontology --maxtxinblock 120000 --gaslimit 0 --rest --localrpc --disableeventlog --loglevel 2

三、测试步骤

使用go-sdk构造一批不同的ONT转账交易，确保其hash不一样，每笔交易的转账数额为1； 启动ontology测试网络，共7个节点； 查询交易发送的目标账户的余额，并记录； 使用JMeter将这批交易发送到测试网络上，配置500个线程发送，设置固定吞吐量定时器控制发送速率；记录开始发送交易时间。 查看节点日志，通过log中numtx观察落账交易数量，出现第一个非空块时记录时间，发送完毕后，连续出现三个以上的空块时，可认为交易已经处理完毕，取最后一个非空块的时间作为落账结束时间； 查询交易发送的目标账户的余额，并记录； 计算余额差值，除以测试时间，即可得TPS。

四、Jmeter配置

线程数与发送次数配置：

LoopController.loops=6000，ThreadGroup.num_threads=500；前者代表一个线程发送的交易的次数，后者代表开启的线程数，二者相乘得出的值为发送的交易数，此处为3,000,000

发送速率配置： 使用固定吞吐量定时器配置交易发送速率，此处为每分钟360,000，即每秒发送6,000笔交易，见下图：

五、交易发送情况

可以看出共发送了3,000,000笔交易，耗时00:08:19，即499秒，则交易发送速度为6012笔/s

六、出块情况

七、性能分析

目前用7个节点测试，TPS达到了5300以上。

测试过程中，使用不同的发送速率，不同的交易量进行测试，测试结果TPS都达到了5000以上。最终的测试结果，也就是VBFT的峰值TPS，超过了5500，达到5536左右。