如何配置Fabric出塊引數來達到“最大”TPS

對于引數的了解

在討論有關最大tps的問題之前，我們首先要了解Fabric出塊的四個引數之間是如何作業的，
從結論上，Fabric會優先于PreferredMaxBytes，AbsoluteMaxBytes，MaxMessageCount這三個引數，最后是BatchTimeout，

避免落入batch timeout

我們以如下配置Probe發起對于Fabric的性能測驗，

BatchTimeout：20
MaxMessageCount：320
AbsoluteMaxBytes：20
PreferredMaxBytes：20480

得到結果如下：

從tape的log中，我們可以發現最后一個塊實際上很大程度的影響了fabric的tps，

Time     5.89s  Block     33    Tx    320
Time     5.98s  Block     34    Tx    320
Time     6.04s  Block     35    Tx    320
Time     6.09s  Block     36    Tx    320
Time    24.14s  Block     37    Tx     80
time="2020-12-11T09:27:48Z" level=info msg="Completed processing transactions."
tx: 10000, duration: 24.143673413s, tps: 414.187180

因此，這個發現表明，

推論一：我們最好不要依賴一個過大的batchtimeout值來觸發fabric出塊，

PreferredMaxBytes，AbsoluteMaxBytes，MaxMessageCount的關系

那么，PreferredMaxBytes，AbsoluteMaxBytes，MaxMessageCount三個引數之間如何相互影響？
我們以如下配置Probe發起對于Fabric的性能測驗，

BatchTimeout：20
MaxMessageCount：10,20,40
AbsoluteMaxBytes：20
PreferredMaxBytes：4

得到結果如下：

從tape的log中，我們可以發現無論如何配置MaxMessageCount，我們的塊中永遠只有1筆交易，

Time    63.75s  Block  10000    Tx      1
Time    63.75s  Block  10001    Tx      1
Time    63.76s  Block  10002    Tx      1
Time    63.76s  Block  10003    Tx      1
Time    63.77s  Block  10004    Tx      1
Time    63.77s  Block  10005    Tx      1
time="2020-12-11T09:43:16Z" level=info msg="Completed processing transactions."
tx: 10000, duration: 1m3.770693352s, tps: 156.811844

4k大小的PreferredMaxBytes在測驗中只能支持一個1tx
基于我們的測驗，一筆交易的大小約為4kb，因此我們調整PreferredMaxBytes并且再次觀察，

BatchTimeout：20
MaxMessageCount：320，640
AbsoluteMaxBytes：20
PreferredMaxBytes：512

tape log(512k 約等于 135 tx，即3.8k/block)

Time     6.33s  Block     67    Tx    135
Time     6.37s  Block     68    Tx    135
Time     6.39s  Block     69    Tx    135
Time     6.43s  Block     70    Tx    135
Time     6.48s  Block     71    Tx    135
Time     6.51s  Block     72    Tx    135
Time     6.56s  Block     73    Tx    135
Time     6.59s  Block     74    Tx    135
Time     6.62s  Block     75    Tx    135
Time     6.67s  Block     76    Tx    135
Time     6.70s  Block     77    Tx    135
Time     6.75s  Block     78    Tx    135
Time     6.78s  Block     79    Tx    135

符合預期，因此我們可以簡單的得出一個推論，這三個引數實際上都是限制block中有多少筆交易的引數，

推論二：在tx大小恒定的情況下，（或者我們可以以均值取代等方式）塊內交易數目為PreferredMaxBytes/tx size，MaxMessageCount， AbsoluteMaxBytes/tx size中的最小值，

Fabric TPS的上限是什么？

硬體上限

我們說任何性能的理論上限是整個網路的上限，也就是整組設備中某個設備I/O，或其他的最小值，
也就是說，無論我們如何優化這四個引數，我們也無法將fabric的tps上限超過網路中某塊網卡的最大承載能力，

引數失效

因此，為了追求最大的TPS我們需要盡可能的讓Fabric某些控制引數失效，來達到這一目的，數學證明如下：

數學表達

從上文中我們將PreferredMaxBytes，AbsoluteMaxBytes，MaxMessageCount視為控制一個塊內有多少交易，
即：

block size = min(PreferredMaxBytes，MaxMessageCount * tx size， AbsoluteMaxBytes)

或：

tx size = min(PreferredMaxBytes / tx size，MaxMessageCount， AbsoluteMaxBytes / tx size)

推論三： Fabric網路的TPS，可以表達為kb/s或者tx/s，如下：

tps(kb/s) = min(PreferredMaxBytes，MaxMessageCount * tx size， AbsoluteMaxBytes)/batchtimout

或者

tps = min(PreferredMaxBytes / tx size，MaxMessageCount， AbsoluteMaxBytes / tx size)/batchtimout

如何實作

現實上來說，業務一般會限制BatchTimeout或者MaxMessageCount，或者我們可以從這兩個引數入手，
在如下示例中，

基于BatchTimeout

在同樣的BatchTimeout下，調整MaxMessageCount，基于

tps = min(PreferredMaxBytes / tx size，MaxMessageCount， AbsoluteMaxBytes / tx size)/batchtimout

不斷的調整MaxMessageCount直到上限，
我們以如下 來配置Probe發起對于Fabric的性能測驗，

得到結果如下：

基于MaxMessageCount

在同樣的MaxMessageCount下，調整BatchTimeout，基于

tps = min(PreferredMaxBytes / tx size，MaxMessageCount， AbsoluteMaxBytes / tx size)/batchtimout

不斷的調整BatchTimeout直到上限，
我們以如下 來配置Probe發起對于Fabric的性能測驗，
得到結果如下：

后記

本文基于Probe，Tape以及test-network，基于fabric 2.2版本image，在mac上單機進行的測驗，

Probe專案現在在招募維護者，歡迎大家反饋，貢獻～
原文地址： https://github.com/SamYuan1990/Probe/blob/main/doc/HowToConfigFabricParameters_ZH.md
專案地址：https://github.com/SamYuan1990/Probe