借助源码包中的sample_clients
- 单独编译出orderer二进制
- 运行测试
- 启动orderer服务
- 分别对orderer的rpc服务发请求
这里我们使用的是centOS，避免了windows的一些配置问题
ps：实质上从源码上看orderer的broadcast和deliver都是需要别人请求才响应，所以我们可以模拟client发送信息到orderer排序，模拟peer向orderer发送请求区块的信息，至于出块等操作我们就直接可以利用配置。
测试方案
-
对运行的orderer的两个服务进行模拟请求获取性能分析报告，根据TOP等来看系统的整体性能
-
raft的容错测试下的性能分析报告
// TODO
测试目的
借助工具来看orderer的接受消息和发送区块主要的性能损耗点
操作步骤
- 编译运行orderer节点，注意开启pprof服务
- 进入broadcast_msg,发起broadcast请求
go run client.go
- 进入deliver_stdout，发起deliver请求
go run client.go
- 通过改变各种配置参数和client.go里的请求代码进行调试分析
分析文件
链接：https://pan.baidu.com/s/1klJh_4ddoiG3mr0326qiPQ
提取码：vdxu
（2是broadcast，5是deliver）
Broadcast
Graph
Top
Flame Graph
Peek
Source
Deliver
Graph
Top
Flame Graph
Peek
Source
结论
- 大量日志的写操作是需要消耗高性能的
- 对于区块的Next请求是orderer的deliver服务的主要消耗点
- 写区块这个操作虽然不是频繁操作但也是高耗能操作
- IO操作是高并发的一处高消耗点