以docker启动fabric网络，高并发大规模数据插入账本时，容器磁盘占用率急速升高

首先我们测试fabric网络的并发量：

Fabric性能验证实验

目的：

验证fabric在并发请求（invoke、query）下的性能

实验条件：

在centos7系统下搭建fabric，基于fabric v1.0.6版本，go version go1.9.2 linux/amd64，Docker version 18.01.0-ce, build 03596f5，docker-compose version 1.18.0, build 8dd22a9

安装fabric所需环境，可以参考http://blog.csdn.net/btqszl/article/details/78182525

实验网络拓扑：

 

实验步骤：

1. 实验基于fabric官方提供的e2e例子开启区块链网络

cd $GOPATH/src/github.com/hyperledger/fabric/examples/e2e_cli

./network_setup.sh up

开启网络后，见到下图表示网络开启成功

 

docker ps -a

网络中包含两个组织共4个peer节点，一个orderer排序节点，网络中已经安装$GOPATH/src/github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02/chaincode_example02.go智能合约，智能合约主要是一个转账操作，例如A转B多少资金

2. 利用go web框架beego对fabric-go-sdk的invoke（修改）和query（查询）接口进行restful封装,然后开启go web服务，等待响应并发请求，见下图表示beego服务已经开启

3. 采用压力测试工具ab对go web服务进行压力测试

压测命令：

ab -c 1 -n 100 -p "test.txt" -T "application/json" 'http://localhost:2323/chaincode/invoke'

ab -c 1 -n 100 -p "test.txt" -T "application/json" 'http://localhost:2323/chaincode/query'

实验结果：

fabric的invoke并发性能异常，怀疑是因为并发请求时，多次交易(A转账B)基于账本同一状态，当前面的交易提交到账本后，账本状态改变，导致后面的交易变为无效，所以修改智能合约，使得invoke操作变为插入操作(key->value),然后修改beego服务程序，使得invoke操作每次插入不同的key(自增)，再次对invoke和query接口进行压力测试

测试结果：

Invoke

invoke在并发不超过330时，不会产生失败请求

Query

query在并发不超过500时，不会产生失败请求,和修改前测试结果一样

 df -h   查看磁盘占用空间

发现是容器的log增长过快，修改docker compose启动文件, 关闭容器log问题解决