fabric orderer的sample_clients编译以及性能测试

借助源码包中的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

fabric orderer的sample_clients编译以及性能测试

Top

fabric orderer的sample_clients编译以及性能测试

Flame Graph

fabric orderer的sample_clients编译以及性能测试

Peek

fabric orderer的sample_clients编译以及性能测试

Source

fabric orderer的sample_clients编译以及性能测试

Deliver

Graph

fabric orderer的sample_clients编译以及性能测试

Top

fabric orderer的sample_clients编译以及性能测试

Flame Graph

fabric orderer的sample_clients编译以及性能测试

Peek

fabric orderer的sample_clients编译以及性能测试

Source

fabric orderer的sample_clients编译以及性能测试

结论

  • 大量日志的写操作是需要消耗高性能的
  • 对于区块的Next请求是orderer的deliver服务的主要消耗点
  • 写区块这个操作虽然不是频繁操作但也是高耗能操作
  • IO操作是高并发的一处高消耗点
上一篇:Redis常见客户端异常汇总


下一篇:JedisConnectionException: java.net.SocketTimeoutException: