Тест производительности Hyperledger Fabric

Question

Во время попытки добиться производительности с Hyperledger Fabric, о которой команда IBM сообщила в своей статье Hyperledger Fabric: распределенная операционная система для разрешенных цепочек блоков , я столкнулся с некоторыми проблемами и ошибками. Я собрал всю полезную информацию и хочу поделиться ею с сообществом HF. Кроме того, у меня есть пара вопросов к разработчикам Fabric относительно его производительности.

Описание цели

Сеть Hyperledger Fabric v1.1.0, развернутая с использованием Cello на четырех экземплярах c5.9xlarge (36vCPU):

{
    fabric001: {
      cas: [],
      peers: ["anchor@peer1st.main"],
      orderers: ["orderer1st.orderer"],
      zookeepers: ["zookeeper1st"],
      kafkas: ["kafka1st"]
    },
    fabric002: {
      cas: [],
      peers: ["worker@peer2nd.main"],
      orderers: ["orderer2nd.orderer"],
      zookeepers: ["zookeeper2nd"],
      kafkas: ["kafka2nd"]
    },
    fabric003: {
      cas: [],
      peers: ["worker@peer3rd.main"],
      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) для своих тестов. Я создал простое приложение nodejs, которое взаимодействует с сетью Fabric с помощью SDK и предоставляет HTTP API для нагрузочных тестов. Это приложение не имеет состояния и может быть легко масштабировано. Для нагрузочного тестирования я использую инструмент ЯндексТанк. Я выполнил два вида тестов с высокой нагрузкой: запрос (запросы через peer001 в состояние Fabric, когда блокчейн пуст) и вставка (транзакции внутри блокчейна).

Результаты

CouchDB как база данных состояний

• Результаты запроса : https://overload.yandex.net/101153. При ~ 1100 об / мин задержка начинает увеличиваться. Но экземпляр Fabric не загружен и имеет много свободных ресурсов. На рисунке ниже вы можете увидеть использование ЦП и памяти сетевыми контейнерами Fabric на экземпляре fabric001 во время теста. 100% загрузка процессора означает одну полную загрузку vCPU. Также peer001 печатает много похожих журналов ошибок (не полный вывод, только крошечная часть, я могу поделиться с вами, если это необходимо): https://gist.github.com/krabradosty/9780cacc92fcdeaa0c36377a91727ade

• Результаты вставки : https://overload.yandex.net/101217. При ~ 600 об / с ухудшение задержки очень быстрое. Раньше есть медленно, но, в любом случае, существуют. Использование ЦП и памяти контейнеров fabric003 на рисунке ниже: Много журналов ошибок от однорангового узла (опять же, не полный вывод): https://gist.github.com/krabradosty/3810151b8e101d8279cc705aef22863e

Исходя из этого, я могу заключить, что у Fabric Peer есть проблемы с соединением CouchDB под нагрузкой.

Мои вопросы: Знает ли Fabric Comminity об этой ошибке? Есть ли у вас планы, как это решить?

LevelDB как база данных состояний

• Результаты запроса : https://overload.yandex.net/102035. Использование ЦП и памяти контейнеров fabric001 на рисунке ниже: В блокчейне нет ошибок, я вижу только ухудшение задержки.
• Вставьте результаты : https://overload.yandex.net/102040. Использование ЦП и памяти контейнеров fabric001 на рисунке ниже: Агрессивная латентная деградация начинается с ~ 850 об / с. Нет ошибок в блокчейне.

Мои вопросы: Какова причина этого ухудшения латентности? Почему я не могу достичь производительности 3500 rps, о которой IBM сообщает в своей статье? Какие планы у сообщества Fabric по улучшению производительности?

Answer 1

Fabric - система массового обслуживания.При высокой нагрузке время ожидания увеличивается в геометрической прогрессии (свойство очереди) и, следовательно, задержка транзакции.Однако для golevelDB мы должны получить как минимум 2000 tps с низкой задержкой.

Из графика использования ЦП видно, что только 16 виртуальных ЦП полностью использованы из 36 виртуальных ЦП.Какое значение установлено для validatorPoolSize в core.yaml для каждого пира?Вы можете установить это значение равным или меньшим, чем размер блока, и проверить, увеличивается ли пропускная способность.

Производительность будет отличаться в зависимости от рабочей нагрузки

1. (fabcar vs fabcoin),
2. диска (hdd vs ssd, локальная против подключенной сети),
3. генератор нагрузки (CLI против SDK),
4. метод генерации нагрузки ( открытая система против закрытой системы против некоторого распределения) и
5. пропускная способность сети (не менее 1,6 Гбит / сза 2700 тпс).

Кроме того, убедитесь, что генератор нагрузки не становится узким местом.Было бы лучше, чтобы задержку можно было разделить на (задержку одобрения, задержку при упорядочении, задержку принятия) и собирать информацию об использовании других ресурсов, таких как сеть и диск, чтобы можно было легко идентифицировать узкое место.

Вы можете обратиться кнаш технический документ под названием Сравнительный анализ производительности и оптимизация Hyperledger Fabric .Мы провели всестороннее эмпирическое исследование.С levelDB мы должны получить как минимум 2000 tps с низкой задержкой.