Производительность и показатели

Iroha производительность зависит от рабочей нагрузки, топологии validator, условий сети и консенсусных настроек. TPS Таким образом, номер полезен только в том случае, если он связан с бегом по эталону с фиксированной конфигурацией.

Для планирования потенциала рассматривать производительность как оперативную рамку:

• сеть принимает запрошенную ставку транзакции
• обязать задерживаться в рамках целевого бюджета
• транзакционные очереди остаются ограниченными
• консенсус не опирается на повторяющиеся изменения просмотра или пути восстановления

Используйте эту страницу для оценки того, находится ли развертывание в состоянии высокой, средней или низкой производительности для данного числа узлов, порога задержки сети и цели TPS.

Что нужно измерять

Начиная с поверхностей оператора, подвергшихся воздействию Torii:

export TORII=http://127.0.0.1:8180

curl -s "$TORII/status" | jq .
curl -s -H 'Accept: application/json' "$TORII/v1/sumeragi/status" | jq .
curl -s "$TORII/v1/sumeragi/phases" | jq .
curl -s "$TORII/v1/sumeragi/rbc" | jq .
curl -s "$TORII/v1/sumeragi/params" | jq .
curl -s "$TORII/metrics" > metrics.prom

Вы можете попробовать один и тот же шаблон для чтения только против общественного Taira:

TAIRA=https://taira.sora.org

curl -fsS "$TAIRA/status" \
  | jq '{blocks, txs_approved, txs_rejected, queue_size, peers}'

curl -fsS "$TAIRA/v1/time/status" \
  | jq '{healthy: .health.healthy, peers, samples_used, rtt_count: .rtt.count}'

curl -fsS "$TAIRA/metrics" \
  | grep -E '^(block_height|queue_size|sumeragi_tx_queue_depth|txs|view_changes)' \
  | head -n 20

Публичные Taira показатели полезны для изучения названий сигналов. Не используйте их в качестве чисел производственной мощности для собственного развертывания.

Такие же snapshots консенсуса доступны через CLI:

iroha --config ./localnet/client.toml --output-format text ops sumeragi status
iroha --config ./localnet/client.toml --output-format text ops sumeragi phases
iroha --config ./localnet/client.toml --output-format text ops sumeragi telemetry
iroha --config ./localnet/client.toml ops sumeragi params

Видимость телеметрии зависит от конфигурированного профиля. Используйте extended когда вам нужен /metrics, и используйте full во время тестирования, когда вам также нужны подробные маршруты оператора Sumeragi.

telemetry_enabled = true
telemetry_profile = "full"

Загрузочные полосы

Используйте эти полосы для наблюдаемого пробега при целевом пропускной способности. Y TPS и бюджет задержки L миллисекунд. Используйте рабочую нагрузку достаточно долго, чтобы включать в себя нагрев, стабильное состояние и хотя бы один период ожидаемой пиковой нагрузки.

Группа	Условия	Значение .
Высоко .	Принятая пропускная способность находится на уровне Y или выше, задержка обязательств p95 ниже 0.8 * L, очереди остаются ниже 10% мощности, а счетчики для изменения зрения/восстановления - плоские	У развертывания есть место для требуемой рабочей нагрузки
Средний	Принятая пропускная способность приближается к Y, задержка передачи сообщений p95 ниже L, очереди стабильны ниже 50% мощности, а изменения в просмотре редки.	Развертывание работает, но терпимость к взрывам ограничена.
Низкий .	Принятая пропускная способность ниже Y, задержка обязательств p95 превышает L, очереди растут во время работы или счетчики изменения зрения / обратного давления постоянно повышаются	Запрошенная рабочая нагрузка превышает по меньшей мере одно ограничение.

Ключевое правило - направление очереди. Если представленный TPS превышает обязательство TPS, и очередь продолжает расти, развертывание перегружается даже если короткие образцы выглядят здоровыми.

Счет узлов и кворум

Большее количество валидаторов улучшает толерантность к ошибкам, но увеличивает затраты на координацию, подпись и создание сети. Sumeragi реализация:

• Количество валидаторов n получает бюджет ошибки f = floor((n - 1) / 3)
• для n >= 4, кворум по определению составляет 2f + 1;
• для n <= 3 требуются все валидаторы для обязательства;
• наблюдатели сверстников синхронизируют блоки, но не голосуют, не предлагают или не собирают

Валидаторы	Ошибка бюджета	Примите кворум	Примечание о пропускной способности
От 1 до 3	0 практический оффлайн отставание	все валидаторы	Используется для разработки и небольших испытаний; любой отсутствующий валидатор может задержать обязательства
4	1	3	Общий минимум для толерантности к одной ошибке
7	2	5	Более устойчивая, с большим объемом голосования и распространения информации
10	3	7	Более высокие затраты на координацию; большее значение имеет регулирование сети и коллекторов

При оценке "X-узлов" отделить валидаторы голосования от наблюдателей. Добавление наблюдателей обычно стоит меньше, чем добавление валидаторов, но наблюдатели все равно потребляют сплетни блоков, синхронизацию блоков, диск и пропускную способность сети.

Факторы, влияющие на производительность

Форма рабочей нагрузки

Тот же TPS может быть дешевым или дорогим в зависимости от того, что делает каждая сделка.

• количество инструкций на одну транзакцию
• Количество подписей и алгоритмы подписания
• размер байта транзакции и разгруженный объем полезной нагрузки
• соотношение чтение/запись
• размеры метаданных и операции с активами
• умный контракт, запуск и стоимость исполнения IVM
• загрузка запроса на одних и тех же сверстников

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

Время согласования

Время действия Sumeragi регулируется эффективными параметрами Sumeragi:

• block_time_ms
• commit_time_ms
• min_finality_ms
• pacing_factor_bps
• Время действия фазы NPoS при включении режима NPoS

Проверьте их:

iroha --config ./localnet/client.toml ops sumeragi params
curl -s "$TORII/v1/sumeragi/params" | jq .

Снижение временных целей может улучшить задержку только в то время, как сетевые, накопительные и исполнительные слои могут идти в ногу. После просмотра изменений, появления нехватки полезной нагрузки или обратного давления, снижение времени обычно усугубляет производительность.

Коллектор Фанаут

Настройки коллектора влияют на то, как быстро сближаются голоса:

• sumeragi.collectors.k контролирует, сколько избирателей собирает голоса на высоту
• sumeragi.collectors.redundant_send_r управляет дополнительным голосованием после местного отсрочки
• sumeragi.collectors.parallel_topology_fanout добавляет топологическую форму вместе с коллекторами.

Увеличение пропускной способности может уменьшить задержку в более крупных или менее надежных сетях, но также увеличивает трафик. Сравните совокупную доступность и коллекторную телеметрию с показателями задержки и обратного давления перед изменением этих значений:

iroha --config ./localnet/client.toml --output-format text ops sumeragi telemetry

Условия сети

Результаты консенсуса чувствительны к:

• RTT между validators
• нервы и потеря пакета
• пропускная способность для блочных полезных нагрузок и RBC кусков;
• асимметричные связи между регионами
• NAT, защитная стена или поведение эстафеты, которое задерживает подключение сверстников

В качестве правила планирования установить бюджет задержки достаточно высоким, чтобы охватить несколько поездок валидатора и время выполнения диска. Если сеть p95 RTT уже близка к желаемой задержке commit p95, цель не является реалистичной.

В очереди и в пределах

Настройки входа и очереди определяют, сколько давления взрыва может поглотить одноклассник:

• queue.capacity
• queue.capacity_per_user
• queue.transaction_time_to_live_ms
• ограничения на транзакции генезиса, такие как максимальные подписи, инструкции, байты и декомпрессированные байты.
• лимиты очереди p2p и консенсусные ограничения входа

Высокая пропускная способность очереди может скрыть перегрузку на некоторое время, но это не увеличивает устойчивую пропускную способность.

Оборудование и хранение

Измерить каждого проверяющего, не только лидера:

• CPU насыщение во время валидации, проверки подписи и исполнения
• давление на память от очередей, снимков и активных RBC сессий
• задержка записи диска для хранения блоков и снимков
• насыщенность сети передачи/получания
• опциональные настройки аппаратного ускорения при использовании рабочей нагрузкой

Самый медленный валидатор голосования может определить заднюю задержку сети.

Сигналы Прометея

Метрические имена могут варьироваться в зависимости от создания профиля и набора функций. Сначала проверьте /metrics на своем узле, а затем создавайте панели управления вокруг доступных серий.

Общие сигналы включают в себя:

Сигнал .	Примеры Прометея	Что посмотреть ?
Принятая пропускная способность	sum(rate(txs{type="accepted"}[5m]))	Должен достигать или превышать целевой показатель TPS в стабильном состоянии
Отказы	sum(rate(txs{type="rejected"}[5m]))	Должно быть объясняемо с помощью плана испытаний
Обязательное задержка .	histogram_quantile(0.95, sum(rate(commit_time_ms_bucket[5m])) by (le))	Сравнить p95/p99 с бюджетом задержки
Глубина очереди	queue_size, sumeragi_tx_queue_depth	Следует оставаться на границе во время пикового загрузки .
Насыщенность очереди	sumeragi_tx_queue_saturated	Поддерживаемые не нулевые значения среднего перегрузки
Просмотр изменений	view_changes, sumeragi_view_change_suggest_total, sumeragi_view_change_install_total	Растущие значения указывают на сроки, топологию, полезную нагрузку или проблемы с сетью
Отброшенные сообщения	dropped_messages, sumeragi_consensus_message_handling_total	Падение во время загрузки обычно объясняет рост латентности .
RBC давление	sumeragi_rbc_store_pressure, sumeragi_rbc_backpressure_deferrals_total	Не нулевые точки давления для восстановления полезной нагрузки или задержки хранения
Примите кворум	sumeragi_commit_signatures_counted, sumeragi_commit_signatures_required	Перечисленные подписи должны быстро достичь требуемого кворума .

Когда метрика существует только в /v1/sumeragi/status, сделайте снимок на JSON в одном и том же экземпляре артефактов, что и скрап "Прометей".

Оценка рабочего процесса

1. Определить сценарий:

   • количество валидаторов и наблюдателей
   • режим консенсуса
   • Цель TPS
   • бюджеты по обязательному опозданию p95 и p99
   • смесь транзакций
   • ожидаемая сеть RTT, jitter и пропускная способность

2. Зарегистрируйте эффективную конфигурацию:

   iroha --config ./localnet/client.toml --output-format json ops sumeragi params \
     > artifacts/sumeragi-params.json
   curl -s "$TORII/v1/sumeragi/collectors" \
     > artifacts/sumeragi-collectors.json

3. Запустить рабочую нагрузку на цель TPS.

4. Запишите состояние и показатели в начале, середине и конце пробега.

5. Классифицируйте пробег с помощью таблицы показателей производительности.

6. Если диапазон средний или низкий, измените один фактор за раз и повторяйте.

Образец отчета ссылки

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

• Iroha флаги обязательства, выпуска и функций
• Количество валидаторов и наблюдателей
• режим консенсуса и параметры Sumeragi
• сборник k, излишняя передача r и топология fanout
• телеметрический профиль
• оборудование, хранение и OS подробности
• сеть RTT, предположения о jitter, loss и bandwidth
• смесь транзакций и размеры полезной нагрузки
• предлагаемый TPS и продолжительность работы
• принятые/отклоненные TPS
• p50/p95/p99 задержка выполнения обязательств
• глубина очереди и насыщение
• просмотр изменений, пропущенных сообщений, давления RBC и счетчиков недостающей полезной нагрузки;
• CPU, память, диск и использование сети на каждого валидатора

Без этих подробностей номер TPS должен рассматриваться как анекдотический.

Схожие страницы

• Тесты хаоса с Izanami
• конечные точки Torii
• Управление Iroha 3 через CLI
• Ссылка на конфигурацию сверстников