首先我们测试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问题解决
