что значит 100 tps
Сколько TPS в вашем блокчейне?
Любимым вопросом о любой распределенной системе от нетехнического специалиста является “Сколько tps в вашем блокчейне?”. Однако, названное в ответ число обычно имеет мало общего с тем, что хотел бы услышать вопрошающий. На деле, он хотел спросить “подойдет ли ваш блокчейн под мои бизнес требования”, и эти требования — это не одно число, а множество условий — здесь и отказоустойчивость сети, и требования к финальности, размеры, характер транзакций и множество других параметров. Так что ответ на вопрос “сколько tps” вряд ли будет простым, и почти никогда не будет полным. Распределенная система с десятками и сотнями узлов, выполняющих довольно сложные вычисления, может находиться в огромном количестве различных состояний, связанных с состоянием сети, содержимым блокчейна, техническими сбоями, экономическими проблемами, атаками на сеть и множеством других причин. Этапы, на которых возможны проблемы с производительностью отличаются от традиционных сервисов, а сервер блокчейн-сети — это сетевой сервис, сочетающий в себе функционал базы данных, web-сервера и torrent-клиента, что делает его крайне сложным в плане профиля нагрузки на все подсистемы: процессор, память, сеть, storage
Так получилось, что децентрализованные сети и блокчейны являются довольно специфическим и непривычным софтом для разработчиков централизованного ПО. Поэтому я хотел бы осветить важные аспекты производительности и устойчивости децентрализованных сетей, подходы к их измерению и нахождению bottlenecks. Мы рассмотрим различные проблемы производительности, ограничивающие скорость предоставления сервиса пользователям блокчейнов и отметим особенности, характерные для этого вида софта.
Этапы запроса сервиса клиентом блокчейна
Для того, чтобы честно говорить о качестве любого более-менее сложного сервиса, нужно учесть не только средние значения, но и максимальные/минимальные, медианы, персентили. Теоретически, можно говорить о 1000 tps в каком-нибудь блокчейне, но если 900 транзакций выполнились с огромной скоростью, а 100 — «зависли» на несколько секунд, то среднее время, собранное по всем транзакциям — это не совсем честная метрика для клиента, который за несколько секунд не смог завершить сделку. Временные «ямы», вызванные пропущенными раундами консенсуса или разделением сети могут сильно испортить сервис, который на тестовых стендах показывал прекрасную производительность.
Чтобы идентифицировать такие bottleneck-и необходимо хорошо понимать этапы, на которых реальный блокчейн может испытывать затруднения при обслуживании пользователей. Давайте опишем цикл доставки и процессинга транзакции, а также получения нового состояния блокчейна, из которого клиент может убедиться, что его транзакция была обработана и учтена.
Теперь давайте подробней разберем эти этапы и опишем потенциальные проблемы с производительностью на каждом этапе. В отличие от централизованных систем, мы также рассмотрим исполнение кода на клиентах сети. Довольно часто при измерении tps время процессинга транзакций собирают с нод, а не с клиента — это не совсем честно. Клиенту плевать, насколько быстро нода запроцессила его транзакцию, самое важное для него — момент, когда достоверная информация об этой транзакции, включенной в блокчейн, станет доступной ему. Именно эта метрика и является по сути временем исполнения транзакции. Это означает, что разные клиенты, даже отправляя одну и ту же транзакцию, могут получить совершенно разные времена, которые зависят от канала, загруженности и близости ноды, и т.п. Так что совершенно необходимо измерять это время на клиентах, поскольку именно этот параметр нужно оптимизировать.
Подготовка транзакции на стороне клиента
Начнем с первых двух пунктов: транзакция формируется и подписывается клиентом. Как ни странно, это тоже может быть bottleneck-ом производительности блокчейна с точки зрения клиента. Это непривычно для централизованных сервисов, которые все вычисления и операции с данными забирают себе, а клиент просто готовит короткий запрос, способный запросить большой объем данных или вычислений, получая готовый результат. В блокчейнах клиентский код становится все более и более мощным, а блокчейн ядро — все более и более легковесным, а массивные вычислительные задачи принято отдавать клиентскому софту. В блокчейнах существуют клиенты, которые могут готовить одну транзакцию довольно долго (я говорю о различных merkle proof-ах, succinct proof-ах, threshold подписях и других сложных операциях на стороне клиента). Хорошим примером легкой on-chain верификации и тяжелой подготовки трназакции на клиенте является доказательство принадлежности списку на основе Merkle-tree, вот статья.
Также не стоит забывать, что клиентский код не просто шлет транзакции в блокчейн, а сначала запрашивает состояние блокчейна — а эта деятельность может влиять на загруженность сети и блокчейн нод. Так что, проводя измерения, разумным будет эмулировать как можно более полным образом поведение клиентского кода. Даже если в вашем блокчейне обычные легкие клиенты, которые ставят обычную цифровую подпись на простейшую транзакцию по переводу какого нибудь asset-а, с каждым годом массивных вычислений на клиенте все равно становится больше, криптоалгоритмы крепчают, и эта часть процессинга может превратиться в весомый bottleneck в будущем. Поэтому будьте осторожны, и не пропустите ситуацию, когда в транзакции, длящейся 3.5s, 2.5s уходит на подготовку и подписание транзакции, и 1.0s- на отправку в сеть и ожидание ответа. Для оценки рисков появления этого bottleneck нужно собирать метрики с клиентских машин, а не только с блокчейн-нод.
Отправка транзакции и мониторинг ее статуса
Следующим этапом является отправка транзакции в выбранную блокчейн-ноду и получение статуса принятия ее в пул транзакций. Этот этап похож на обычное обращение к базе данных, нода должна записать транзакцию в пул и начать распространять информацию о ней через p2p сеть. Подход к оценке производительности здесь похож на оценку работы традиционных микросервисов Web API, причем сами транзакции в блокчейнах могут обновляться, активно менять статус. Вообще, обновление информации о транзакции в некоторых блокчейнах может произойти несколько раз, например при переключениями между форками цепочки или когда BP сообщают о намерении включить транзакцию в блок. Ограничения на объем этого пула и количество транзакций в нем могут оказывать влияние на производительность блокчейна. Если пул транзакций забит до максимально возможного размера, или не помещается в оперативной памяти — производительность сети может резко упасть. Блокчейны не имеют централизованных средств защиты от потока мусорных сообщений, и, если блокчейн поддерживает транзакциии большого объема и низкие комиссии, это может привести к переполнению пула транзакций — это еще один потенциальный bottleneck производительности.
В блокчейнах, клиент оправляет транзакцию в любую понравившуюся ему ноду блокчейна, хеш транзакции обычно известен клиенту еще до отправки, так что все что ему требуется — добиться соединения и после передачи ожидать когда блокчейн изменит свое состояние, включив его транзакцию. Заметим, что измеряя «tps» можно получить совершенно разные результаты для различных способов подключения к ноде блокчейна. Это может быть обычный HTTP RPC или WebSocket, позволяющий реализовать паттерн «subscribe». Во втором случае клиент получит уведомление раньше, а нода потратит меньше ресурсов (в основном памяти и трафика) на ответы о состоянии транзакции. Так что при измерении «tps» необходимо учитывать способ подключения клиентов к нодам. Поэтому, для оценки рисков появления этого bottleneck-а, benchmark блокчейна должен уметь эмулировать клиентов и с WebSocket и с HTTP RPC запросами, в долях, соответствующих реальным сетям, а также менять характер транзакций и их размер.
Для оценки рисков появления этого bottleneck нужно также собирать метрики с клиентских машин, а не только с блокчейн-нод.
Передача транзакций и блоков по p2p сети
В блокчейнах для передачи между участниками транзакций и блоков используется peer-to-peer (p2p) networking. Транзакции распространяются по сети, начиная с одной из нод, пока не достигают peer-ов-block producer-ов, которые упаковывают транзакции в блоки и с помощью того же p2p распространяют новые блоки по всем нодам сети. Основа большинства современных p2p сетей — различные модификации протокола Kademlia. Вот хороший краткий обзор этого протокола, а вот — статья с различными измерениями в сети BitTorrent, по которой можно понять — что этот вид сетей сложнее, и менее предсказуем, чем жестко сконфигурированная сеть централизованного сервиса. Также, вот статья про измерение различных интересных метрик для нод Ethereum.
Если вкратце, каждый peer в таких сетях поддерживает свой собственный динамический список других peer-ов, у которых запрашивает блоки информации, которые адресуются по содержимому. При получении запроса peer либо отдает нужную информацию, либо передает запрос следующему псевдослучайному peer-у из списка, а получив ответ, передает его запрашивающему и на некоторое время кеширует его, отдавая этот блок информации раньше в следующий раз. Таким образом популярная информация оказывается в большом числе кешей у большого числа peer-ов, а непопулярная постепенно вытесняется. Peer-ы ведут учет кто кому сколько передал информации, и сеть старается стимулировать активных раздающих, повышая их рейтинг и обеспечивая им более высокий уровень сервиса, автоматически вытесняя неактивных участников из списков peer-ов.
Итак, транзакцию теперь надо распространить по сети, чтобы ее увидели block-producer-ы и включили в блок. Нода активно «раздает» новую транзакцию всем желающим и слушает сеть, ожидая блок, в индексе которого будет появится нужная транзакция, чтобы уведомить ожидающего клиента. Время, пока сеть перебрасывает друг другу информацию о новых транзакциях и блоках в p2p сетях зависит от очень большого количества факторов: количества честных, работающих рядом (с сетевой точки зрения) нод, «прогретости» кешей этих нод, размера блоков, транзакций, характера изменений, географии сети, числа нод и еще множества факторов. Комплексные измерения метрик быстродействия в таких сетях — сложное дело, необходимо одновременно оценивать время обработки запросов и на клиентах, и на peer-ах (блокчейн нодах). Проблемы в каком либо из p2p механизмов, неверное вытеснение и кеширование данных, неэффективное управление списками активных peer-ов, и множество других факторов могут стать причиной задержек, влияющих на эффективность всей сети в целом, и этот bottleneck — наиболее сложный для анализа, тестирования и интерпретации результатов.
Процессинг цепочки блоков и обновление state database
Самой важной частью работы блокчейна является алгоритм консенсуса, его применение к новым, полученным из сети блокам и процессинг транзакций с записью результатов в state database. Добавление нового блока в цепочку и следующий за этим выбор основной цепочки должен работать максимально быстро. Однако, в реальной жизни «должен» не значит «работает», и можно, например, представить себе ситуацию когда две длинные конкурирующие цепочки постоянно переключаются между собой, меняя метаданные тысяч транзакций в пуле на каждом переключении, и производя постоянные откаты состояния state database. Этот этап, в плане определения bottleneck проще, чем сетевой p2p слой, т.к. исполнение транзакций и алгоритм консенсуса строго детерминированы, и измерять что-либо здесь проще.
Главное — не спутать случайную деградацию производительности этого этапа с проблемами сети — ноды медленней отдают блоки и информацию об основной цепочке и для внешнего клиента это может выглядеть как медленная сеть, хотя проблема кроется совсем в другом месте.
Для оптимизации производительности на этом этапе полезно собирать и мониторить метрики с самих нод, и включать в них те, которые касаются обновления state-datаbase: число блоков, обрабатываемых на ноде, их размер, число транзакций, количество переключений между форками цепочек, число невалидных блоков, время работы виртуальной машины, время фиксации данных и т.д. Это позволит не спутать сетевые проблемы с ошибками в алгоритмах процессинга цепочек.
Процессящая транзакции виртуальная машина может быть полезным источником информации, способной оптимизировать работу блокчейна. Количествo аллокаций памяти, количество read/write инструкций, и другие метрики, касающиеся эффективности исполнения кода контрактов могут дать много полезной информации разработчикам. В то же время, смарт-контракты — это программы, а значит в теории они могут потреблять любые из ресурсов: cpu/memory/network/storage, так что процессинг транзакций — довольно неопределенный этап, который вдобавок сильно меняется при переходе между версиями и при изменении кода контрактов. Поэтому метрики, касающиеся процессинга транзакций также нужны для эффективной оптимизации производительности блокчейна.
Получение клиентом уведомления о включении транзакции в блокчейн
В это месте обязательно присутствует отправка полного времени, которое пришлось затратить клиенту на ожидание ответа от блокчейна, именно это время пользователь будет ожидать подтверждения в своем приложении, и именно его оптимизация является основной задачей разработчиков.
Заключение
В результате, можно описать типы операций, выполняющихся в блокчейнах и разделить их на несколько категорий:
Вообще технические требования к нодам современных блокчейнов крайне серьезные — это быстрые CPU для криптографии, большой объем оперативной памяти для того, чтобы хранить и быстро обращаться к state database, сетевое взаимодействие, использующее большое число одновременно открытых соединений, объемный storage. Такие высокие требования и обилие различных типов операций неизбежно приводят к тому, что ресурсов у нод может не хватать, и, тогда любой из рассмотренных выше этапов может стать очередным bottleneck-ом для общей производительности сети.
Разрабатывая и оценивая производительность блокчейнов, вам придется учитывать все эти моменты. Для этого нужно собирать и анализировать метрики одновременно с клиентов и нод сети, искать корреляции между ними, оценивать время предоставления сервиса клиентам, учитывать все основные ресурсы: cpu/memory/network/storage, понимать как они используются и влияют друг на друга. Все это делает сравнение скоростей различных блокчейнов в виде «сколько TPS» крайне неблагодарным занятием, так как существует огромное количество различных конфигураций и состояний. В больших централизованных системах, кластерах из сотен серверов, эти проблемы также сложны и также требуют сбора большого числа различных метрик, но в блокчейнах, из за p2p сетей, виртуальных машин, процессящих контракты, внутренней экономики, число степеней свободы гораздо больше, что делает тест даже на нескольких серверах непоказательным и показывающим лишь крайне примерные значения, почти не имеющие связи с реальностью.
Поэтому, при разработке в ядре блокчейна, для оценки производительности и ответа на вопрос «улучшилось ли по сравнению с прошлым разом» мы используем довольно сложный софт, оркестрирующий запуск блокчейна с десятками узлов и автоматическим запуском бенчмарка и сбором метрик, без этой информации крайне сложно отлаживать протоколы, работающие со множеством участников.
Так что, получив вопрос «сколько TPS в вашем блокчейне?», предложите собеседнику чаю и уточните, готов ли он ознакомиться с десятком графиков а также выслушать все три короба проблем производительности блокчейнов и вашими предложения по их решению.
Как измерять производительность блокчейн сетей. Основные метрики
Существует много метрик, относящихся к логике и качеству работы блокчейна. Они помогают определить узкие места в коде и найти логические и оптимизационные проблемы в алгоритмах консенсуса и финальности в блокчейнах. Любая разработка распределенных систем, в том числе блокчейнов, требует анализа работы сразу множества узлов. Они позволяют команде проекта следить за состоянием всей блокчейн-сети, видеть проблемы с отдельными нодами, детектировать появление DoS атак на сеть и многое другое. Давайте рассмотрим основные из них. Let’s dive in.
“Transactions-per-second”
В случае распределенных систем, TPS — это очень капризное и неоднозначное число, которое не всегда отражает реальное качество предоставляемого пользователям сервиса. Измерения TPS пришли к нам из распределенных баз данных. TPS в базах данных — это некоторые стандартизованные для теста транзакции или их наборы (сколько то INSERT, сколько-то UPDATE, столько DELETE-ов на фоне постоянных SELECT) для жестко заданной конфигурации кластера или вообще на одной машине. Эти метрики обычно дают только приближенные оценки производительности распределенных БД или блокчейнов, так как время процессинга транзакции может сильно варьироваться в зависимости от множества факторов.
Базы данных, ориентированные на консистентность (см. “CAP-теорема”) не фиксируют транзакцию, пока не получат достаточное число подтверждений от других нод и это медленно. А базы данных, ориентированные на Availability, считают успешной транзакцию, которую просто удалось записать на диск. Они сразу отдают клиенту обновленные данные и это очень быстро (хотя в будущем, эта транзакция может быть откачена назад). Также, если транзакции, используемые в бенчмарке, обновляют лишь одну ячейку с данными, TPS явно будет выше, чем в случаях, когда транзакции могут затрагивать много ячеек и блокировать друг друга. Алгоритмы работы с этими блокировками в каждой БД реализованы по своему — как раз поэтому мы и не видим “соревнований по TPS” между Oracle, MSSQL, PostgreSQL с одной стороны и MongoDB, Redis, Tarantool с другой — уж очень разные внутренние механизмы и разные задачи.
По моему мнению, “измерить TPS” блокчейна означает провести полный комплекс измерений его производительности:
Чтобы говорить о заветных “transactions per second”, нужно описать все условия (число валидаторов, их гео-распределение, уровень packetloss и т.п.) и описать логику бенчмаркинга. В блокчейнах просто накатить транзакцию на внутреннюю БД не означает ее принятие консенсусом. Например, в случае c Proof-of-Work, статистически, транзакции не завершаются вообще никогда, и, если транзакция включена в блок на одной машине, это не означает, что она будет принята всей сетью (например, в случае победы другого форка).
Если в блокчейне есть дополнительный алгоритм обеспечения финальности транзакций (EOS, Ethereum 2.0, парачейны Polkadot, использующие консенсус с финальностью GRANDPA), то временем процессинга транзакции можно считать промежуток между тем, как нода “увидела” транзакцию и следующим финализированным блоком, куда эта транзакция была включена. Такие, более близкие к реальности “TPS” нечасто встретишь в обещаниях проектов. Они, естественно, ниже описанных в Whitepaper-ах, но зато максимально информативны.
Так что еще раз предупреждаю, в термин “TPS” может быть вложено очень много разных смыслов. Будьте скептичны и требуйте подробностей.
Метрики, специфичные для блокчейн сетей
Local TPS
Число обработанных нодой транзакций и max/avg/min время их обработки на локальной ноде очень удобно измерять, так как функции, выполняющие эту операцию, обычно явно выделены в коде. Можно просто измерить, сколько времени транзакция работала, обновляя state database. Эти транзакции, возможно, пока не приняты консенсусом, но уже прошли валидацию, и нода уже может отдавать клиенту обновленные данные (рассчитывая, что не появится форк цепочки).
Эта метрика не очень честная: если в качестве основной будет выбран другой форк цепочки, то статистику по откаченным транзакциям нужно тоже откатывать. Но для тестирования этим почти всегда можно пренебречь.
Часто, именно это число пишут в кратких отчетах: “у нашего блокчейна вчера получилось 8 000 tps”, так как ее просто измерить — достаточно одной запущенной ноды и скрипта, который ее нагружает. В этом случае отсутствует сетевая задержка, которая замедляет достижение сетью консенсуса, а метрика показывает быстродействие state database без влияния сети. Это число не является реальной пропускной способностью блокчейн-сети, но показывает предел, к которому она будет стремиться, если консенсус и сеть будут достаточно быстрыми.
Результат работы любой блокчейн-транзакции — несколько атомарных обновлений storage. Например, платежная транзакция в Bitcoin — это удаление нескольких старых UTXO (delete) и добавление нескольких новых UTXO (insert), а в Ethereum — это исполнение короткого кода смарт-контракта и, опять же, обновление нескольких пар “ключ-значение”. Количество этих “атомарных” операций записи могут быть отличной метрикой, позволяющей определять узкие места в storage-подсистеме и внутренней логике транзакций.
Также, блокчейн-ноды могут быть реализованы на нескольких языках программирования — так надежнее. Это нужно учитывать, оценивая производительность сети, например, нода Ethereum существует в имплементациях на Rust и Go. Другие блокчейны также стремятся иметь дополнительные имплементации для надежности.
Local produced blocks amount
Эта несложная метрика показывает, какой валидатор сколько блоков произвел. Она является продуктом консенсуса и ее можно считать основной для оценки “полезности” для сети отдельных валидаторов.
Зарабатывая на каждом блоке, валидаторы заинтересованы в стабильной работе и безопасности своих машин. Это число помогает определить, кто из валидаторов-кандидатов наиболее квалифицирован, защищен и подготовлен для работы в публичной сети с активами реальных пользователей. Значение метрики можно публично проверить, просто скачав блокчейн и посчитав кто сколько блоков произвел.
Finality и Last Irreversible Block
В сетях с явно реализованой финальностью (EOS, Ethereum, Tendermint, Polkadot, etc ) помимо основного, быстрого консенсуса (в котором достаточно одной подписи валидатора на блок) часть блоков требует согласования группой валидаторов. Эти блоки считаются финальными, а алгоритм сбора подписей — финальностью. Задача финальности — сделать так, чтобы все транзакции, включенные в блокчейн до финализированного блока уже никогда не были бы откачены и не заменены другим форком цепочки. Это защита от атаки double spend в proof-of-stake сетях, и способ быстро, за несколько секунд, вернуть пользователю надежное подтверждение криптовалютной транзакции.
С точки зрения пользователя блокчейна, транзакция завершается не в тот момент, когда он принята нодой, а когда появился блок, который финализирует цепочку, в которой находится транзакция. Чтобы финализировать блок, валидаторы должны получить этот блок по p2p сети, и обменяться подписями друг с другом. Именно здесь и проверяется реальная скорость блокчейна, ведь пользователю важен именно момент финализации блока с его транзакцией, а не просто принятие и запись ее на диск одной из нод.
Алгоритмы финальности также различаются, пересекаются и объединяются с основным консенсусом (to read: Casper в Ethereum, Last Irreversible Blocks в EOS, GRANDPA в Parity Polkadot и их модификации, например MixBytes RANDPA).
Для сетей, где финализируется не каждый блок, полезной метрикой является отставание последнего финализированного блока от текущего последнего блока. Это число показывает, насколько отстают валидаторы, согласуя правильную цепочку. Если отставание большое, значит алгоритм финализации требует дополнительного анализа и оптимизации.
Другие блокчейн-метрики
Остальные метрики обычно сильно зависят от типа консенсуса, поэтому представлять их в числе основных не очень правильно. В числе таких параметров, например: количество форков цепочки, их длина в блоках, заполняемость блоков транзакциями и т.п. По ним можно определить ситуации разделения сети или быстро локализовать проблемы конкретного валидатора.
P2P слой
Крайне важно помнить о промежуточной основе блокчейн-сетей — peer-to-peer подсистеме. Именно она вносит неопределенные задержки в доставке блоков и транзакций между валидаторами. Когда количество валидаторов небольшое, они локализованы, списки peer-ов жестко прописаны, все работает хорошо и быстро. Но стоит добавить валидаторов, разнести ноды географически и сэмулировать packetloss, как в “tps” появляются существенные провалы.
Например, при тестировании консенсуса EOS с дополнительным алгоритмом finality, увеличение числа валидаторов даже до 80-100 машин, разнесенных по четырем континентам несильно повлияло на скорость достижения finality. В то же время, увеличение packetloss сильно повлияло на отставание финальности, что говорит о необходимости дополнительной настройки p2p слоя для большей устойчивости к потере сетевых пакетов, а не к большому latency. К сожалению, различных настроек и факторов велико, поэтому, только бенчмарки позволяют понять эффективное количество валидаторов, которые обеспечивают достаточно комфортную скорость работы блокчейна.
Устройство p2p подсистемы можно понять из документации, например, по libp2p или документацию по протоколу Kademlia или BitTorrent.
Важными метриками для p2p являются:
Например, большое число misses при обращении к данным означает, что запрашиваемыми данными обладают лишь небольшое число нод, и они не успевают раздать их всем желающим, а объем принятого/отданного p2p трафика позволит установить ноду, имеющую проблемы с сетевой конфигурацией или каналом.
Системные метрики блокчейн-нод
Стандартные системные метрики блокчейн-нод описаны в большом числе источников, поэтому опишу их кратко. Их роль — помогать искать узкие места и ошибки во всех частях кода, показывая какие подсистемы ноды наиболее загружены и какими задачами.
Говорят о том, сколько вычислений выполняет процессор. Если CPU load высокий, значит нода что-то вычисляет, активно использует логику или FPU (в блокчейнах почти не используется). В блокчейнах это может быть, например, из за того, что нода проверяет электронные подпиcи, процессит транзакции с тяжелой криптографией или делает сложные вычисления.
CPU можно “разрезать” ещё на несколько полезных метрик, чтобы понять, какие части кода наиболее затратны. Например, system — код ядра, user — пользовательские процессы, io — ожидание i/o от медленных внешних устройств(диск/сеть) и т.д. Вот хорошая статья по теме.
Memory
Современные блокчейны используют key-value базы-данных (LevelDB, RocksDB), которые постоянно держат в памяти “горячие” данные. Как и в любых нагруженных сервисах, здесь всегда возможны утечки памяти в результате ошибок или целенаправленных атак на код ноды. Если потребление нодой памяти растет, либо резко увеличилось, то, скорее всего, это вызвано увеличением числа ключей в state database, большими очередями транзакций, либо увеличением числа сообщений между разными подсистемами ноды. Недозагрузка памяти может говорить о возможном увеличении лимитов на данные в блоках или максимальную сложность транзакции.
Для full-нод, котоhttps://habrastorage.org/webt/qa/sn/m5/qasnm5bougkjuagneevjkpg9x0w.pngрые отвечают клиентам сети, важными также являются метрики файлового кеша. Клиенты обращаются к различным частям state database и логу транзакций. Это порождает подъем с диска старых блоков, которые могут вытеснять новые блоки, что, в свою очередь замедляет отдачу ответов клиенту.
Network
Основные внутренние метрики network — это объем трафика в байтах, число отправленных и принятых сетевых пакетов по каждому и протоколов, packet loss ratio. В блокчейнах тим метрикам часто не уделяют большого внимания, т.к. блокчейны пока еще не обрабатывают траназакции со скоростью в 1 Gbit/sec.
Существуют блокчейн-проекты, позволяющие пользователям делиться своим wifi или предоставлять услуги хранения и передачи файлов или сообщений. При тестировании таких сетей, количество и качество трафика через сетевой интерфейс становится крайне важными метриками, так переполненный сетевой канал влияет на все остальные сервисы на машине без исключения.
Storage
Дисковая подсистема — это самый медленный компонент в любых сервисах и часто бывает причиной серьезных проблем с производительностью. Избыточное логгирование, неожиданно пришедший backup, неудобный паттерн чтения/записи, большой суммарный объем блокчейна — все это может привести к существенному замедлению работы ноды или к серьезно завышенным требованиям к железу.
Лог транзакций технически можно рассматривать как WAL (WAL ) для state database, поэтому важны те метрики storage, которые позволяют искать узкие места в механизмах современных key-value баз данных. Это количество read/write IOPS, max/min/avg latency и множество других метрик, помогающих оптимизировать дисковые операции.
Заключение
Итак, мы рассмотрели несколько наборов метрик, которые могут давать очень ценную информацию о работе блокчейн сети и возможностях для ее оптимизации. Подытоживая, можно собрать их в три группы:
Каждая из групп важна по своему, так как в каждой из подсистем возможно существование ошибок, ограничивающих работу других компонентов, а замедление даже небольшого количества валидаторов может оказывать серьезное влияние на всю сеть. Также, наиболее хитрые ошибки в алгоритмах консенсуса и финальности возникают только при большом потоке транзакций или изменении параметров консенсуса. Для их анализа требуются воспроизводимые условия тестирования и сложные сценарии нагрузки.
Разработка блокчейнов — это всегда оркестрация несколькими машинами, скрипты для раскладки конфигов и согласованного запуска нод и бенчмарков, сервера для сбора метрик и логов со всех машин. Поэтому, при разработке своего блокчейна, предусмотрите найм квалифицированного девопса — он окажет неоценимую поддержку команде разработки. Удачи!