web-dev-qa-db-fra.com

Test de performance du tissu Hyperledger

En essayant d'atteindre les performances avec Hyperledger Fabric, que l'équipe IBM a signalées dans son article Hyperledger Fabric: un système d'exploitation distribué pour les blockchains autorisées , j'ai rencontré des problèmes et des erreurs. J'ai collecté toutes les informations utiles et je souhaite les partager avec la communauté HF. J'ai également quelques questions à poser aux développeurs de Fabric sur ses performances.

Description de la cible

Réseau Hyperledger Fabric v1.1.0 déployé à l'aide de Cello sur quatre instances aws c5.9xlarge (36vCPU):

{
    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 est désactivé.

Configuration du canal Fabric (tous les autres paramètres sont les paramètres par défaut):

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

J'ai effectué des tests pour CouchDB et LevelDB en tant que base de données d'état. J'utilise le chaincode Fabcar officiel (implémentation Golang) pour mes tests. J'ai créé une application nodejs simple qui interagit avec le réseau Fabric à l'aide du SDK et expose l'API HTTP pour les tests de charge. Cette application est sans état et peut être facilement mise à l'échelle. Pour les tests de charge, j'utilise l'outil YandexTank. J'ai effectué deux types de tests avec une charge élevée: requête (requêtes via peer001 à l'état Fabric lorsque la blockchain est vide) et insert (transactions dans la blockchain).

Résultats

CouchDB comme base de données d'état

  • Résultats de la requête : https://overload.yandex.net/10115 . À ~ 1100 rps, la latence commence à augmenter. Mais l'instance Fabric n'est pas chargée et dispose de nombreuses ressources gratuites. Sur la figure ci-dessous, vous pouvez voir l'utilisation du CPU et de la mémoire par les conteneurs réseau Fabric sur l'instance fabric001 pendant le test. 100% d'utilisation du processeur signifie une charge complète de vCPU. fabric001 container instances (couchdb, query) Peer001 imprime également beaucoup de journaux d'erreurs similaires (pas une sortie complète, juste une petite partie, je peux la partager avec vous si nécessaire): https://Gist.github.com/krabradosty/9780cacc92fcdeaa0c36377a91727ade =

  • Insérez les résultats : https://overload.yandex.net/101217 . À ~ 600 rps, la dégradation de la latence est très rapide. Avant, c'est lentement, mais de toute façon, existe. Utilisation du CPU et de la mémoire des conteneurs fabric003 sur la figure ci-dessous: fabric001 container instances (couchdb, insert) Beaucoup de journaux d'erreurs du pair (encore une fois, pas de sortie complète): https://Gist.github.com/krabradosty/3810151b8e101d8279cc705aef22863e

Sur cette base, je peux conclure que Fabric Peer a des problèmes avec la connexion CouchDB sous la charge.

Mes questions: Fabric comminity est-il au courant de ce bogue? Avez-vous des plans pour le résoudre?

LevelDB en tant que base de données d'état

  • Résultats de la requête : https://overload.yandex.net/102035 . Utilisation du CPU et de la mémoire des conteneurs fabric001 sur la figure ci-dessous: fabric001 container instances (leveldb, query) Il n'y a aucune erreur de la blockchain, je vois juste une dégradation de la latence.
  • Insérez les résultats : https://overload.yandex.net/10204 . Utilisation du CPU et de la mémoire des conteneurs fabric001 sur la figure ci-dessous: fabric001 container instances (leveldb, insert) La dégradation de latence agressive commence à ~ 850 rps. Aucune erreur de la blockchain.

Mes questions: Quelle est la cause de cette dégradation de latence? Pourquoi je ne peux pas atteindre les performances de 3500 rps qu'IBM rapporte dans son article? Quels plans la communauté Fabric a-t-elle pour améliorer les performances?

performanceload-testinghyperledger-fabricblockchain
14
Dmitry Pugachev

Fabric est un système de mise en file d'attente. Avec une charge élevée, le temps d'attente augmente exponentiellement (propriété de mise en file d'attente) et donc la latence des transactions. Cependant, pour golevelDB, nous devrions obtenir au moins 2000 tps avec une faible latence.

D'après le graphique d'utilisation du processeur, il semble que seuls 16 vCPU sont entièrement utilisés sur 36 vCPU. Quelle valeur est définie pour validatorPoolSize dans core.yaml pour chaque homologue? Vous pouvez définir cette valeur égale ou inférieure à la taille de bloc et vérifier si le débit augmente.

La performance différerait en fonction de la

  1. charge de travail (fabcar vs fabcoin),
  2. disque (hdd vs ssd, local vs réseau connecté),
  3. générateur de charge (CLI vs SDK),
  4. méthode de génération de charge ( système ouvert vs système fermé vs une certaine distribution) et
  5. bande passante réseau (au moins 1,6 Gbps pour 2700 tps).

Assurez-vous également que le générateur de charge ne devient pas un goulot d'étranglement. Il serait préférable de diviser la latence (latence d'approbation, latence de commande, latence de validation) et de collecter d'autres ressources telles que le réseau et le disque afin que le goulot d'étranglement puisse être facilement identifié.

Vous pouvez vous référer à notre document technique intitulé Performance Benchmarking and Optimizing Hyperledger Fabric . Nous avons mené une étude empirique complète. Avec levelDB, nous devrions obtenir au moins 2000 tps avec une faible latence.

8
senthil nathan