Настройка высокопроизводительного клиента Ethereum

Я хочу настроить сервер (или набор серверов), который может действовать как узел Ethereum, на который я могу отправлять большое количество запросов со скоростью до 100 в секунду для получения данных из цепочки блоков, например учетной записи. балансы, транзакции и т. д. (например, Etherscan). Поправьте меня, если я ошибаюсь, но я не думаю, что такая система могла бы быть возможна с обычным клиентом четности или geth, работающим на одном сервере с данными цепочки на SSD, поэтому я думаю о том, чтобы сделать следующие:

  1. Настройте клиент четности с SSD на сервере A, который будет работать как обычный узел
  2. Синхронизируйте данные цепочки с другим SSD на сервере B
  3. Настройте клиент четности на сервере B, который не подключен к сети Ethereum и использует данные цепочки, скопированные с сервера A. Не обрабатывает транзакции.
  4. Транзакции, балансы и т. Д. Можно запрашивать в RPC-сокете сервера B.

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

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


person IntegerSynergy    schedule 06.02.2018    source источник


Ответы (2)


Поправьте меня, если я ошибаюсь, но я не думаю, что такая система могла бы быть возможна с обычным клиентом Parity или Geth, работающим на одном сервере с данными цепочки на SSD.

Я счастлив вас поправить: Parity может легко обрабатывать 1_000 запросов RPC в секунду на аппаратном обеспечении потребительского уровня.

Если вам нужно 10_000 запросов в секунду, вы все равно можете достичь этого с помощью одного экземпляра Parity на высокопроизводительном корпоративном сервере с 128 ГБ + RAM и резервным флеш-хранилищем Raid-0, обязательно настройте огромный размер кеша с помощью Parity. :

parity --cache-size 65536

Вы даже можете пойти дальше в оптимизации, поместив всю цепочку блоков в память, установив для --data-dir значение tmpfs.

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

Раскрытие информации: я работаю на Parity. Я думаю, что аналогичная статистика верна и для Geth.

person Afr    schedule 08.02.2018

Думаю, что оптимальным вариантом будет предварительная обработка блоков. Запустите экземпляр клиента Ethereum, выполните итерацию по всем блокам и предварительно обработайте их (извлеките всю необходимую информацию и сохраните ее в базе данных). Это даст больше гибкости для ваших запросов.

Допустим, вам нужен список транзакций из определенного аккаунта. Это невозможно сделать с текущим ETH RPC API (я имею в виду не оптимизированным способом). Лучше всего предварительно обработать все блоки, извлечь все транзакции и расположить их в базе данных, чтобы вы могли запрашивать транзакции, поступающие с определенного адреса.

Запуск API поверх созданной вами базы данных повысит производительность вашего сервера.

person Iulian Rotaru    schedule 07.02.2018