原始社区版fabric
bitcoin:~5tps
ETH:~15tps
ETH 2.0: 10000 tps
fastfabirc1.4:20000tps
https://github.com/tonycai/The-Journal-of-Blockchain
区块链三个核心：去中心化、共识机制、不可篡改
如何配置Fabric出块参数来达到“最大”TPS
https://www.processon.com/view/link/5f3c06ec7d9c0806d41fec86#map
https://github.com/Hyperledger-TWGC/fabric-performance-wiki
grpc接收到的block数据进行反序列，然后缓存
grpc压缩
3. 使用hashtable代替fabric中的leveldb
CPTS 云性能测试服务（Cloud Performance Test Service）
fabric TIP 上限
1. 硬件上限
我们也无法将fabric的tps上限超过网络中某块网卡的最大承载能力。
（百度超级链）
)Fabric网络结构(网络带宽、磁盘IO、计算资源等)，配置参数(如区块大小、背书策略、通道数量、状态数据库等)，共识算法（solo,kafka,pbft等）都会影响评测后果，很难构建反映fabric 全貌的测试模型；
Fabric 交易过程剖析
在Fabric交易过程中，波及不同的角色，每个角色承当不同的性能，节点（Peer）可细分为背书节点（Endorser peer）和提交节点（Committer peer），共识由排序（Orderer）角色实现。交易流程如下：
(1)应用程序客户端通过SDK向区块链网络发动一个交易提案（Proposal），交易提案把带有本次交易要调用的合约标识、合约办法和参数信息以及客户端签名等信息发送给背书节点（Endorser）。
(2)背书节点（Endorser）收到交易提案（Proposal）后，验证签名并确定提交者是否有权执行操作，验证通过后执行智能合约，并将后果进行签名后发还给应用程序客户端。
(3)应用程序客户端收到背书节点（Endorser）返回的信息后，判断提案后果是否统一，以及是否参照指定的背书策略执行，如果没有足够的背书，则停止解决；否则，应用程序客户端把数据打包到一起组成一个交易并签名，发送给Orderers。
(4)Orderers对接管到的交易进行共识排序，而后依照区块生成策略，将一批交易打包到一起，生成新的区块，发送给提交节点（Committer）；
(5)提交节点（Committer）收到区块后，会对区块中的每笔交易进行校验，查看交易依赖的输入输出是否合乎以后区块链的状态，实现后将区块追加到本地的区块链，并批改世界状态。
客户端通过Fabric实现交易，要感知三个步骤（收集背书，提交排序和确认后果），而传统的数据库的读写，只有发动申请，期待确认即可。如果应用经典的测试工具如JMeter,须要将fabric sdk进行包装RESTFul接口，减少了评测的复杂度。侥幸的是，2017年5月超级账本社区推出Caliper，容许用户通过一系列预置的用例来测试特定的区块链技术实现。Caliper生成的报告将会蕴含一系列区块链性能指标，如TPS（均匀每秒交易数），时延，系统资源占用等。本文的评测后果均为Caliper工具来测试生成。
查问吞吐量（Query Throughput）：每秒解决的查问申请量
共识吞吐量（Consensus Throughput）：每秒解决的共识申请量
一致性吞吐率（Consistency Throughput）：每秒实现的同步业务数
均匀时延（Avg Latency）：实现一次事务的均匀耗时
失败率（Fail Rate）：呈现业务失败（含超时）的比例