Новый транзакционный максимум EOSIO продемонстрирован в Jungle Testnet: 9179 TPS (транзакций в секунду) (правка 1)

8 min readDec 6, 2018

Пререлизный EOS Dawn v2.0 был опубликован ровно год назад 5 декабря 2017 года.

https://github.com/EOSIO/eos/releases/tag/dawn-v2.0.0

Недавно группа Блок Продюсеров проверила лимиты EOSIO на новом Jungle Testnet 2.0. Серии тестов проводились в среду 28 ноября, четверг 29 ноября и в понедельник, 4 декабря.

Участвовавшие команды (в алфавитном порядке): Attic Lab, BlockMatrix, CryptoLions, EOS Barcelona, EOS Rio, EOS Metal, eosDAC, SW/Eden.

Зачем?

Испытание новой методики для более интенсивного стресс-тестирования.
Проверка настройки для разных глобальных переменных.
Ограничение пределов программного обеспечения EOSIO.
Тестирование включало в себя новую методологию, которая позволяла увеличивать объем транзакций, ориентированных на небольшой промежуток времени, отложенные транзакции и настраивать различные глобальные переменные.

Как?

Новая методология тестирования включала строгую синхронизацию часов «спам-узлов», отделяя подготовку и упаковку транзакций от их трансляции по сети. Тестеры называли это “loading the gun”.

Ниже указаны глобальные переменные, которые были скорректированы во время тестирования:

min_transaction_cpu_usage
max_block_cpu_usage

а также эти параметры Nodeoes:

chain-threads
last-block-time-offset-us

Мы также попытались проверить влияние отложенных транзакций.

И наконец, мы скорректировали голосование, чтобы только самые сильные серверы могли создавать блоки в Jungle Testnet во время этого тестирования.

Вот некоторые мощности использовавшиеся для “stress party”

EOSMetal

Один узел BP с процессором Intel 64 ГБ и i7

Один fullnode с 64vcpus и 480 ГБ оперативной памяти, выполняющий 10 процессов nodeos

Один сервер Gun с 64vcpus и 480GB RAM, for shooting

Attic Lab

Один node BP с 64 ГБ и процессор Intel Core i9 9900

Две fullnodes 64 ГБ и процессор Intel Core i7 8700

CryptoLions

Intel Xeon W-2145 Octa-Core, 128 ГБ оперативной памяти DDR4 ECC, SSD HDD, 1 ГБ Интернет и второй такой сервер с жестким диском NVE

Журнал испытаний

День 1 (среда, 28 ноября)

Новые идеи:

Синхронизация «спамеров» и скриптов, которые формировали и упаковывали транзакции в процессе подготовки к их отправке. (Каждый спамер отправил 10 packed packages of 1000.)

Затем cleos провел транзакции.

Используя Ntp daemon для синхронизации времени. Спам приходил одновременно для всех спамеров как импульсы с 5-минутными интервалами, это, доставляло большое удовольствие для BP, поскольку позволяло им делать драматические обратные отсчеты и веселые gif.
Были созданны scripts для отправки массовых transfers с пустыми actions.
Мы стейкали по 200k EOS для всех спамеров, а затем, когда этого оказывалось недостаточно, по 400k EOS.
В первый день тестирования мы не смогли преодолеть лимит в 1998 транзакций на один блок или 3996 TPS. Это число уже довольно давно является максимальным TPS, зафиксированным сетевым монитором EOS (https://eosnetworkmonitor.io/). В один момент, мы даже предположили, что это может быть какое-то жестко закодированное ограничение, ограничивающее это.

EOS Sweden

EOS Barcelona

EOS Rio

Attic Lab

EOS Barcelona — TPS = 3992

Attic Lab — TPS = 3996

Мы были разочарованы, достигнув но не превысив исторические Max TPS 3996

К концу первого дня мы обновились до версии 1.5.0-rc1.

Игорь из EOS Rio предложил: и добавил chain-threads = 8

День 2

Мы экспериментировали с этими глобальными переменными:

min_transaction_cpu_usage

max_block_cpu_usage

Bohdan CryptoLions, [03.12.18 22:57]

1. min_transaction_cpu_usage: 100 -> 80 -> 70 -> 60

2. max_block_cpu_usage: 200000 -> 300000 -> 350000 -> 400000

3. both 1 and 2

Глобальные значения по умолчанию:

{

“max_block_net_usage”: 1048576,

“target_block_net_usage_pct”: 1000,

“max_transaction_net_usage”: 524288,

“base_per_transaction_net_usage”: 12,

“net_usage_leeway”: 500,

“context_free_discount_net_usage_num”: 20,

“context_free_discount_net_usage_den”: 100,

“max_block_cpu_usage”: 200000,

“target_block_cpu_usage_pct”: 2000,

“max_transaction_cpu_usage”: 150000,

“min_transaction_cpu_usage”: 100,

“max_transaction_lifetime”: 3600,

“deferred_trx_expiration_window”: 600,

“max_transaction_delay”: 3888000,

“max_inline_action_size”: 4096,

“max_inline_action_depth”: 4,

“max_authority_depth”: 6}

На этом графике показано на 15% меньше времени выполнения после того как atticlab, обновился до 1.5-rc1? или, может быть, это совпадение…

И тут снова началось веселье:

Большие задержки, о которых сообщают некоторые BP:

Мы изменили этот параметр nodeos, чтобы быстрее закрыть последний блок, считая, что это ускорит синхронизацию следующего продюсера:

last-block-time-offset-us = -300000

Блоки 1025381 и 1025382 содержали наши максимальные транзакции TPS — 9179.

Хотя возле этих блоков были форки. Мы также достигли совершенно чистых 6977 TPS.

Рекорд, который мы установили для транзакций в одном блоке, была 6101. (Block number 1025825).

Воспроизведение работало отлично. (Проблемы с воспроизведением были одной из причин того, почему мы запустили Jungle 2 https://monitor.jungletestnet.io/ прошлую версию мы теперь называем Jungle Classic http://jungle.cryptolions.io/ .)

День 3

Определение повестки дня:

Eric — sw/eden, [29.11.18 20:26]

1. Block Twitter spam txs max?

2. One or two free spaces between each procuder

3. Bnet

4. Deferred tx

5. Different params

What else?

Michael Yeates, [29.11.18 20:26]

deferred transactions

Bohdan CryptoLions, [29.11.18 20:26]

repeat tests for different global params

Bohdan CryptoLions, [29.11.18 20:27]

to test deferred tx we need to create special contract..

И казалось, что мы установили новый рекорд TPS, который был наполовину выше, чем 9179, достигнутая в День 2:

Таким образом, максимальное количество транзакций в одном блоке оказалось равным 13 965.

Но это выглядило странно: действия были низкими, несмотря на высокие транзакции.

(Это было жутко похоже на отравленные блоки в «Jungle Classic» Testnet, в котором содержалась информация о транзакциях без транзакций).

И после небольшого расследования мы обнаружили, что блоки были заполнены истекшими транзакциями:

Ну, и как мы это назовем? Два блока, произведенных за одну секунду, действительно содержали 16 992 транзакции, но они были истекшими.

Это новый рекорд TPS? Или, может быть это, рекорд «eTPS»?

Кстати, монитор Jungle Testnet (https://monitor.jungletestnet.io/) автоматически поймал это число в качестве нового рекорда. CryptoLions вручную изменит его на 9179 и переместит этот рекорд eTPS в Условные Обозначения для дальнейшего использования.

Уроки и возможности:

Увеличение параметра max_block_cpu_usage от 200k до 300k до 400k увеличивает форки, но не разрушает цепочку.
Возможность: Захватить и изучить количество потерянных транзакций и попытаться определить оптимальные настройки в различных условиях.
Снижение min CPU показало хорошие результаты, увеличившись до 5 или 6 тыс. Tps.
Предполагаемый предел в TPS 3996, который был продемонстрирован в EOS Mainnet и который встретился нам на 1-м дне тестирования, по-видимому, был результатом переполнения пропускной способности против min_transaction_cpu_usage.
Надеемся, что данные этих тестов, а также информация, собранная на блокчейне Jungle 2, будут полезными для основных разработчиков EOSIO.

Еще скриншоты и Gifs:

Скриншот от EOSMetal, который готовиться к push 2k * 10.000 транзакций с использованием сервера с 64vcpus и 480GB RAM. Но это не работает, потому что ограничение в 1k push actions (max элементов в массиве).