优化方向

fabric有开源社区和IBM的团队开发，代码上的优化其实没必要作为重点，比如之前讲的验证，fabric已经有了设计提案。
fabric官方和社区的资料来看，我们应该可以从配置上来做到客观的提高。
sdk部分的复用和业务上的减少无效交易

主要配置上的优化方向

背书策略（背书节点和策略的数量）
当前的状态数据库（leveldb，couchdb）
资源分配（硬件配置）
块大小,切块时间等

时间计时器问题

以上是peer部分的profile分析

以上是orderer部分的profile分析

分析

全局搜索 time.NewTicker 相关的代码
是否可以去除，或者将单位调大一些

日志问题

logs日志的实时生成，日志大小增长速度略快，初步测试10笔交易可能在docker的container中日志增加70k，并发肯定会拉低机器的可分配性能。
可以测试一下关闭log

验证问题

看起来在验证占据了比较多的消耗

fabric下一阶段的验证部分的设计规划

docs.google.com/document/d/…

链码部分

将channel等在sdk部分复用
在 Go SDK 的实现中，所有的 cache 都是基于对象 fabsdk.FabricSDK 的，不同的对象中会单独维护各自的 cache 和链接。我们在使用 Go SDK 时，应该避免创建过多的 fabsdk.FabricSDK 对象，在初始化时会向 peer节点发送多个请求，消耗一些资源和较多时间。
优化蛮多的...

网络的部署

www.ibm.com/blogs/block…

At least one peer of each org need to endorse the transactions, for every peer you sended the proporsal they will execute the transaction inside the container and check if it is valid, then if it is valid, they will response with status 200 (This is for every one, individualy).

区块和账本解析工具

blocklator.tinywell.com/

并发测试

orderer

peer

左对齐	右对齐	居中对齐
单元格	单元格	单元格
单元格	单元格	单元格

FISCO BCOS性能提升方案

// TODO

fabric 分析草稿