转自:以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问题解决
今天的文章docker性能损失多大_docker解决了什么问题分享到此就结束了,感谢您的阅读。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/86812.html