goloscore

6 лет назад

Новости Golos•Core. Статус софтфорка 0.16.5 на 16.02.2018.

Добрый день!

Рады сообщить, что команда Golos•Core выложила релиз-кандидат софтфорка 0.16.5. Принимая во внимание интерес делегатов и коммьюнити к софтфорку, мы хотим дополнительно пояснить, как и почему мы решили развивать блокчейн Голоса в сторону использование WebSocket, и какие будут преимущества при развитии в эту сторону.

Блокчейн Голоса - это одна из разновидностей базы данных, состояние которой меняется достаточно быстро ~±3 секунды. И следовательно, клиенты базы данных должны реагировать на эти изменения так же быстро. Целесообразно в этом случае проанализировать те решения, которые имеются в классических базах данных.

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

В случае, когда базы данных завязаны на информацию, поступающую через Интернет (протокол [TCP|https://en.wikipedia.org/wiki/Transmission_Control_Protocol]), непрерывное соединение можно обеспечить только через использование WebSockets (прогрессивный стандарт двусторонней связи с сервером по TCP-соединению, совместимый с HTTP). Много работающих блокчейн-сервисов, в настоящий момент активно вводят в эксплуатацию именно это решение.

Блокчейны поддерживающие websockets:

Bitcoin https://blockchain.info/api/api_websocket
Ethereum https://etherscan.io/apis#websocket
Ripple https://ripple.com/build/websocket-tool/
Cardano https://cardanodocs.com/technical/wallet-frontend/
NEO https://github.com/TakahikoKawasaki/nv-websocket-client

Биржи, поддерживающие websockets:

Bitfinex https://docs.bitfinex.com/docs
BitMEX https://www.bitmex.com/app/wsAPI
Bitstamp https://www.bitstamp.net/websocket/
GDAX https://docs.gdax.com/#websocket-feed
Luno https://www.luno.com/en/api

Websockets - предоставляют возможность наиболее эффективного получения информации с минимальными задержками.

По сравнению с HTTP у WebSockets выше скорость и эффективность передачи благодаря малому размеру передаваемых данных. Протокол позволяет организовывать живой обмен сообщениями между браузером и веб-сервером в реальном времени. Каждая сторона при этом работает сама по себе и при необходимости отправляет данные другой.

Об изменении состояния системы - о событиях - можно узнавать несколькими способами: либо периодически отправляя запросы (polling), например, когда клиент приходит на сервер с запросом на свежие данные, и получает ответ, что новые данные не появились; либо длинные запросы (long polling) — когда клиент посылает «ожидающий» запрос на сервер, а сервер смотрит, есть ли свежие данные для клиента, если их нет, то он держит соединение с клиентом до тех пор, пока эти данные не появятся; либо держать низкоуровневое соединение - когда клиент просит сервер сообщать об изменении состояния системы.

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

Чем выше скорость отклика:

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

Чем меньше объем данных, передаваемых по сети:

Тем меньше нагрузка на сеть, как по объему, так и по скорости.
Тем меньше работы надо сделать БД, чтобы начать обработку данных.
Тем меньше работы надо сделать БД, чтобы отправить ответ клиенту.

Чем более независимы клиент и сервер в последовательности обработки данных:

Тем большей гибкостью обладает сервер в планировании обработки запросов от клиентов.
Тем большей гибкостью обладает клиент в определении стратегии запроса информации.

Однако, Websockets благодаря своей низкоуровневости и уменьшению количества полей в заголовках не может быть закеширован стандартными методами, которыми можно кешировать HTTP. Но это не является проблемой. В нашем понимании - демон не должен заниматься кешированием и другими специфическими функциями, его задача - работать с цепочкой и предоставлять информацию из нее, как классическая база данных. Задача кеширования должна решаться в отдельном от демона процессе, в качестве которого можно использовать любое in-memory хранилище, которые уже оптимизированы для подобного рода задач.

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

Модель ниже демонстрирует как работает реализованный дизайн

Поток исполнение и передачи управления между компонентами системы

В независимости от цвета такой стрелкой происходит логическое перемещение данных между компонентами системы

Легенда к схеме:

1 ) Устанавливаем Websocket-соединение, получаем первое сообщение из соединения

2,3 ) Формируем задачу на исполнение, получаем список зарегистрированных обработчиков сообщений, все заворачиваем в специализированную структуру для обработки в пуле-потоков (threadpool).

4 ) Пул-потоков выбирает свободный поток (thread) для выполнения задачи

5 ) Поток запускает на выполнение полученную задачу.

6 ) Во время выполнения задачи, поток запрашивает необходимые данные из блокчейна

7,8 ) Поток обрабатывает полученные для выполнения задачи значения и формирует результат, который передается в callback для записи в сетевое соединение.

8') Происходит запись результата в сокет

Плюсы:

Использование в порядке, удобном для демона
Уменьшение расхода потребляемых ресурсов вычислительной ноды, за счет уменьшения объемов передаваемых данных
Возможность в будущем асинхронно отвечать на все запросы

Минусы:

Перерасход открытых соединений, так как websockets подразумевает постоянное открытое соединение (решается с помощью установления ограничения на количество портов на демоне и хост-машине).

Ну а теперь самое главное. Давайте посмотрим как же выглядит производительность демона на нагрузочных тестах. Мы взяли две версии демона и попробовали их нагрузить абсолютно одинаковой нагрузкой.

Результаты бенчмарков golosd 0.16.4

Результаты бенчмарков golosd 0.16.5

Единица измерения в миллисекундах. (здесь под пингом подразумевается - latency (задержка))

Входные данные 8 клиентов и с каждого по 1875 запросов на демона (суммарно 15000 запросов).

на версии 0.16.4 средняя задержка: 25-30 мс, общее время выполнения тестов: 62.25 с.
на версии 0.16.5 средняя задержка: 2-3 мс, общее время выполнения тестов: 5.03 с. Учитывая, что часть этого времени - создание соединения между клиентом и сервером.

При тестировании использовалось несколько тяжелых методов (по версии 0.16.4) на чтение.

Новый релиз-кандидат можно найти по ссылке:

https://github.com/GolosChain/golos/releases/tag/v0.16.5RC1

Для всех желающих протестировать софтфорк 0.16.5 организован публичный тестнет: wss://ws.testnet.golos.io (доступен только демон без веб-интерфейса).

P.S. На этой неделе @ropox сообщил о сделанной оптимизации кода в части линейной функции. По-прежнему придерживаемся мнения, что линейная функция сначала должна быть тщательно замоделирована и проанализирована по ряду параметров. К сожалению, на подготовленный код не разработаны unit-тесты (если они в процессе разработки, то ждем инфо - как будут сделаны). Со своей стороны планируем протестировать предложенный ХФ и дать экспертную оценку возможности его принятия.

Мы будем очень рады, если вы поддержите делегата @goloscore. Заходите на страничку https://golos.io/~witnesses и проголосуйте за делегата Golos•Core

Спасибо за внимание и хорошего дня!

С уважением,
Команда Golos•Core @kotbegemot, @korpusenko, @abgvedr, @andreypf, @epexa, @muhazokotuha, @mariadia