借助源码包中的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操作是高并发的一处高消耗点