Это довольно интересные результаты. Всегда приятно видеть, что MegaETH на первом месте : ) Чтобы поставить данные в контекст, задержка от конца до конца для RPC-запроса состоит из трех компонентов: (1) задержка распространения со скоростью света от/к наблюдателю к/от сервера, (2) время, необходимое серверу для получения и постобработки запрашиваемых данных, (3) время, необходимое наблюдателю для загрузки ответа. Как вы упомянули, тестируемые методы RPC являются более легкими как с точки зрения вычислительных затрат, так и с точки зрения объема данных. Это означает, что эксперименты в основном тестировали (1), т.е. задержку распространения между наблюдателями и серверами RPC. Не поймите меня неправильно – RPC MegaETH также довольно сильны в (2) и (3), и было бы интересно увидеть эксперименты, которые их нагружают! Итак, как мы можем оптимизировать задержку распространения? На самом деле, не так много настроек. Во-первых, мы можем развернуть серверы RPC в нескольких географических регионах и автоматически направлять запросы к ближайшему серверу. Это похоже на то, как сети быстрого питания открывают магазины повсюду – всегда есть филиал рядом! Более точно, наличие геораспределенных серверов уменьшает физическое расстояние между пользователями и серверами. Во-вторых, мы можем оптимизировать топологию сети. Даже если это между одной и той же парой отправителя и получателя, задержка распространения варьируется в зависимости от фактического сетевого пути. Например, между восточным побережьем США и Азией задержка может варьироваться в 2 раза в зависимости от того, проходят ли пакеты данных через Тихий океан или через Европу. Иногда есть даже несколько сетевых путей, следуя одному и тому же географическому маршруту; некоторые более загружены, чем другие, что вызывает большую задержку. Это похоже на наличие нескольких автомагистралей на выбор от точки A до точки B. Преимущества задержки, которые вы наблюдали, скорее всего, возникли из-за нашей оптимизации маршрута.
Avaworld
Avaworld15 авг., 21:38
MegaETH Официальный RPC против Thirdweb RPC – Задержка в тестовой сети Я хотел получить прямые данные от MegaEth, не запуская никакую инфраструктуру, и искал самый быстрый способ сделать это. Я использовал "" для проведения простого бенчмарка, чтобы увидеть, как официальный RPC MegaETH сравнивается с сторонним RPC (Thirdweb). Цель заключалась в том, чтобы проверить, какой из них быстрее получит свежие данные из обозревателя из разных частей мира. Тест использовал вызовы RPC `eth_blockNumber` и `eth_getBalance` на тестовой сети MegaETH. Он охватывает 27 регионов AWS на 6 континентах, отправляя запросы один за другим с интервалом в одну секунду. Он отслеживал среднюю задержку, сбои, ошибки 429, успешные запросы и общее время запроса. Вот результаты Все результаты показали, что официальный RPC MegaETH был быстрее на всех шести континентах и во всех 27 регионах. Задержка для MegaETH варьировалась от примерно 126 мс до 238 мс согласно этому тесту. Для Thirdweb задержка варьировалась от примерно 170 мс до 381 мс. У обоих были низкие показатели сбоев, но у MegaETH их было немного меньше, а общее время запроса было постоянно ниже для MegaETH. Для контекста, как правило, в сетях есть как минимум несколько регионов, где сторонний RPC быстрее. Avalanche, Optimism и Ethereum все имеют примеры этого в публичных бенчмарках. См. - Результаты Avalanche C-Chain - Результаты Optimism - Результаты Ethereum Победа MegaETH над Thirdweb везде не является типичной. Моя гипотеза о том, почему официальный rpc MegaETH оказывается на первом месте, заключается в том, что сеть хорошо настроена архитектурно и использует один секвенсор за раз. Я приглашаю @NamikMuduroglu @yangl1996 @0xSami_M поделиться своими мыслями Это тестовая сеть, поэтому цифры могут измениться на основной сети, когда трафик будет больше. Однако на данный момент, если вам нужен самый быстрый и надежный способ получить данные из обозревателя MegaETH, официальный RPC является очевидным выбором. P.S.: Я не эксперт, это всего лишь теоретически и может быть не на 100% точным, так как тестируемые данные были легкими вызовами, также эти результаты были зафиксированы, результаты могут варьироваться, если задействованы более крупные данные в разное время, наконец, я использовал публичный rpc thirdweb, могут быть и другие более быстрые.
12,78K