Сколько одновременных запросов может обрабатывать узел Ethereum?

Так что мы на самом деле очень, очень редко полностью взрывались. Например, во время крупных ICO мы наблюдали 200 тысяч транзакций, отправляемых через узел MEW за один час, что составляет около 55 транзакций в секунду. Каждая транзакция состоит из:

• Загрузка баланса

• Загрузка баланса токенов

• Получение цены на сетевой газ (мы больше этим не занимаемся)

• Оценка газа (каждый раз, когда пользователь меняет поле)

• Получение одноразового номера учетной записи

• На самом деле отправка TX

Это заставило нас получать около 1 млн запросов в час или 277 запросов в секунду. Мы видели, как DDOS (или dapps) достигали 4 миллионов запросов в час (но не в течение длительного периода, как ICO).

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

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

Также существует очень большая разница между внутренней попыткой getBalance или sendRawTX и приемом этих вызовов через API/JSON RPC. Локально мы смогли обработать 10 тыс. транзакций примерно за 7 секунд. Если мы выгрузим 10 000 транзакций в API, потребуется около 40 секунд, чтобы вернуть хэш TX 10 000 разным пользователям, если туда не добавлено 10 000 других вызовов для путаницы.

Итак, чтобы ответить на ваш вопрос, количество открытых файлов в вашем конфигурационном файле, вероятно, сейчас максимальное, что, вероятно, равно 1024. 😉

Узкие места появляются в разных точках, не всегда в самом узле. Мы устранили узкие места с размером пула TX, ЦП, открытыми файлами и многим другим. В настоящее время у нас работает 10 узлов: 5 geth и 5 parity. По какой-то причине у некоторых из нас прямо сейчас возникают проблемы с огромными скачками задержки в самом Parity.

Если вы хотите погрузиться глубже, https://github.com/MyEtherWallet/docker-geth-lb

Этот вопрос был опубликован довольно давно; однако ответы кажутся несколько устаревшими, поскольку опубликованные числа варьируются от сотен до 1024 и менее 2000.

Вот фактический тест:

Аппаратное обеспечение:

Облачный сервер на голом металле

• Процессор: E3-1270v6
• Оперативная память: 32 ГБ
• HD: твердотельный накопитель

Это просто бенчмарк вызовов eth_blockNumber, и у Parity нет проблем с ~40 тыс. запросов/с через HTTP и ~70 тыс. запросов/с через IPC с использованием клиентской библиотеки rust-web3 (версия 0.2.0 на момент написания этой статьи). ).

Конечно, это не показатель реальной производительности. У нас есть служба, которая выполняет более ресурсоемкие вызовы rpc (сочетание parity_pendingTransactionsи trace_transaction, опрос полного пула tx — нет eth_getFilterChanges), и один узел четности обслуживает устойчивые > 20 тыс. запросов / с через конечную точку веб-сокета (пользовательский клиент web3, написанный на Rust , используя библиотеку веб-сокетов ws-rs , однопоточный, неоптимизированный код разработки).

Не уверен, что это поможет, но мой узел Parity на моем ноутбуке способен обрабатывать не более 2000 запросов eth_call в секунду.

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

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

Здесь не по теме. Это, конечно, не принесет награды, но QuickBlocks один раз попадает в RPC (это медленно), а затем кэширует данные на диске (намного предпочтительнее SSD), чтобы они были повторно доставлены намного быстрее при следующем запросе.

Мы наблюдаем устойчивый доступ к тем же данным, что и RPC, с более чем в 100 раз большей скоростью, на ноутбуке Mac и полностью децентрализовано.

Да — мы удвоили требования к объему дискового пространства, да — данные утекают из-под консенсуса (в этом смысле так же происходит с MyEtherWallet и Infura), но это действительно быстро, а со сверхбыстрыми данными мы можем делать все что угодно. интересных вещей, таких как локальное создание таблиц ограничений для токенов ERC20, анализ использования газа контракта и т. д.

Так как ответов пока нет...

Я бы сказал, что число в частной сети, использующей стандартное настольное оборудование, составляет менее 10 000 и, вероятно, ближе к нескольким сотням, в зависимости от характера транзакций. Быстрый веб-сервер, такой как nginx, может обрабатывать несколько больше в одном потоке (см. здесь ). Но вызовы RPC не так просты, как обслуживание статической страницы, которую можно кэшировать. Во- первых, могут быть зависимости для транзакций , которые требуют последовательного выполнения транзакций. Это можно ускорить с помощью спекулятивной оценки на нескольких ядрах. Однако, если вы не храните всю цепочку блоков в оперативной памяти, вам все равно придется иногда обращаться к диску. Хороший SSD может обслуживать порядка 100 000 операций ввода-вывода в секунду, но все же это большой предел для баз данных. Например, Лехтинен обнаружил, чтоего SSD мог выдавать около 1000 операций в секунду .

Помимо этого, ваш компьютер, вероятно, начнет сбрасывать TCP-соединения.

Как видите, я на самом деле не проверял это, и вы должны относиться к этим числам как к таковым!