web-dev-qa-db-ja.com

Hyperledger Fabricのパフォーマンステスト

IBMチームが記事 Hyperledger Fabric：許可されたブロックチェーン用の分散オペレーティングシステム で報告したHyperledger Fabricでパフォーマンスを達成しようとして、いくつかの問題とエラーに直面しました。すべての有用な情報を収集し、HFコミュニティと共有したいと思います。また、Fabric開発者にパフォーマンスについていくつか質問があります。

ターゲットの説明

4つのc5.9xlarge（36vCPU）AWSインスタンスでCelloを使用して展開されたHyperledger Fabric v1.1.0ネットワーク：

{
    fabric001: {
      cas: [],
      peers: ["[email protected]"],
      orderers: ["orderer1st.orderer"],
      zookeepers: ["zookeeper1st"],
      kafkas: ["kafka1st"]
    },
    fabric002: {
      cas: [],
      peers: ["[email protected]"],
      orderers: ["orderer2nd.orderer"],
      zookeepers: ["zookeeper2nd"],
      kafkas: ["kafka2nd"]
    },
    fabric003: {
      cas: [],
      peers: ["[email protected]"],
      orderers: ["orderer3rd.orderer"],
      zookeepers: ["zookeeper3rd"],
      kafkas: ["kafka3rd"]
    },
    fabric004: {
      cas: ["ca1st.main"],
      peers: [],
      orderers: ["orderer4th.orderer"],
      zookeepers: ["zookeeper4th"],
      kafkas: ["kafka4th"]
    }
}

TLSは無効です。

ファブリックチャネル構成（他のすべてのパラメーターはデフォルトです）：

BatchTimeout: 1s
BatchSize:
    MaxMessageCount: 500
    AbsoluteMaxBytes: 200 MB
    PreferredMaxBytes: 50 MB

状態データベースとしてCouchDBとLevelDBの両方のテストを実行しました。公式のFabcarチェーンコード（Golang実装）をテストに使用します。 SDKを使用してFabricネットワークとやり取りし、負荷テスト用のHTTP APIを公開する簡単なnodejsアプリを作成しました。このアプリはステートレスであり、簡単にスケーリングできます。負荷テストには、YandexTankツールを使用しています。高負荷での2種類のテストを実行しました：クエリ（peer001を介したブロックチェーンが空の場合のFabric状態へのリクエスト）と挿入（ブロックチェーン内のトランザクション）。

結果

状態データベースとしてのCouchDB

  • クエリ結果： https://overload.yandex.net/10115 〜1100 rpsでレイテンシーが増加し始めます。ただし、Fabricインスタンスは読み込まれず、多くの空きリソースがあります。次の図では、テスト中にインスタンスfabric001上のFabricネットワークコンテナーによるCPUおよびメモリの使用量を確認できます。 100％のCPU使用率は、1つのvCPUの完全なロードを意味します。 fabric001 container instances (couchdb, query) また、peer001は同様のエラーログを大量に出力します（完全な出力ではなく、必要に応じて共有できます）： https://Gist.github.com/krabradosty/9780cacc92fcdeaa0c36377a91727ade =

  • 結果を挿入： https://overload.yandex.net/101217 。 〜600 rpsのレイテンシー低下は非常に高速です。以前はゆっくりですが、とにかく存在します。下図のfabric003コンテナのCPUおよびメモリ使用量： fabric001 container instances (couchdb, insert) ピアからの多くのエラーログ（完全な出力ではありません）： https://Gist.github.com/krabradosty/3810151b8e101d8279cc705aef22863e

これに基づいて、ファブリックピアには負荷がかかった状態でCouchDB接続に問題があると結論付けることができます。

私の質問：Fabric comminityはこのバグを知っていますか？あなたはそれを解決する方法を計画していますか？

状態データベースとしてのLevelDB

  • クエリ結果： https://overload.yandex.net/102035 。下の図のfabric001コンテナのCPUおよびメモリ使用量： fabric001 container instances (leveldb, query) ブロックチェーンからのエラーはありません。レイテンシの低下が見られます。
  • 結果の挿入： https://overload.yandex.net/10204 。下の図のfabric001コンテナのCPUおよびメモリ使用量： fabric001 container instances (leveldb, insert) アグレッシブなレイテンシーの低下は、〜850 rpsで始まります。ブロックチェーンからのエラーはありません。

私の質問：このレイテンシー低下の原因は何ですか？ IBMの記事で報告されている3500 rpsのパフォーマンスを達成できないのはなぜですか？ Fabricコミュニティはパフォーマンスの改善に関してどのような計画を持っていますか？

performanceload-testinghyperledger-fabricblockchain
14
Dmitry Pugachev

ファブリックはキューイングシステムです。高負荷の場合、待機時間は指数関数的に増加し（キューイングプロパティ）、したがってトランザクションの待ち時間が増加します。ただし、golevelDBの場合、低レイテンシで少なくとも2000 tpsを取得する必要があります。

CPU使用率のプロットから、36個のvCPUのうち、16個のvCPUのみが完全に使用されているように見えます。各ピアのcore.yamlのvalidatorPoolSizeにはどのような値が設定されていますか？この値をブロックサイズ以下に設定し、スループットが増加するかどうかを確認できます。

パフォーマンスはに基づいて異なります

  1. ワークロード（fabcar vs fabcoin）、
  2. ディスク（hdd vs ssd、ローカルvsネットワーク接続）、
  3. ロードジェネレーター（CLIとSDK）、
  4. 負荷生成方法（ オープンシステムvsクローズシステム vs一部の分散）および
  5. ネットワーク帯域幅（2700 tpsで少なくとも1.6 Gbps）。

また、負荷ジェネレーターがボトルネックになっていないことを確認してください。ボトルネックを簡単に特定できるように、レイテンシをさらに（推奨レイテンシ、順序付けレイテンシ、コミットレイテンシ）に分割し、ネットワークやディスクなどの他のリソース使用率を収集できるようにするとよいでしょう。

パフォーマンスベンチマークとHyperledger Fabricの最適化 というタイトルのテクニカルペーパーを参照できます。包括的な実証研究を実施しました。 levelDBでは、低遅延で少なくとも2000 tpsを取得する必要があります。

8
senthil nathan