fabric-gateway-java vs fabric-java-pool 寫測試
fabric-java-pool 是一個將fabric-gateway-java和fabric-sdk-java基礎上封裝爲鏈接池使得開發人員可以像使用jdbc鏈接池那樣使用fabric的個人項目。
爲什麼這麼應用？
我們假設同一組織內的員工採用組織的賬號來授權區塊鏈上的交易。比如同一新聞社的記者或者編輯將他們的文章發佈的同時上鍊做版權認證。
代碼案例&它的原理?
對比fabric-gateway-java
測試結果：
爲什麼會這樣：
先看出塊的設置塊是1s一出的，我們client的tps遠遠不足100000的塊數，因爲fabric-gateway-java監聽了落塊，而fabric-java-pool使用fabric-sdk-java時沒有監聽，所以最快，gateway-pool和gateway性能接近，1m一個請求。
# Batch Timeout: The amount of time to wait before creating a batch
BatchTimeout: 1s
# Batch Size: Controls the number of messages batched into a block
BatchSize:
# Max Message Count: The maximum number of messages to permit in a batch
MaxMessageCount: 100000
# Absolute Max Bytes: The absolute maximum number of bytes allowed for
# the serialized messages in a batch.
AbsoluteMaxBytes: 512 MB
# Preferred Max Bytes: The preferred maximum number of bytes allowed for
# the serialized messages in a batch. A message larger than the preferred
# max bytes will result in a batch larger than preferred max bytes.
PreferredMaxBytes: 512 MB
那麼，我們把塊改小點，10次一出塊
# Batch Timeout: The amount of time to wait before creating a batch
BatchTimeout: 1s
# Batch Size: Controls the number of messages batched into a block
BatchSize:
# Max Message Count: The maximum number of messages to permit in a batch
MaxMessageCount: 10
# Absolute Max Bytes: The absolute maximum number of bytes allowed for
# the serialized messages in a batch.
AbsoluteMaxBytes: 512 MB
# Preferred Max Bytes: The preferred maximum number of bytes allowed for
# the serialized messages in a batch. A message larger than the preferred
# max bytes will result in a batch larger than preferred max bytes.
PreferredMaxBytes: 512 MB
所以我們看到，是檢查落塊機制導致的時間區別。使用pool能夠提升一定的性能，但是性能還是由出塊和落塊決定的。
在每個提交都出塊的情況下對比pool和沒有pool情況下使fabric-gateway-java
