Магазин DApp | Центр Web3 для подій та ігор

Актуальні теми

Ось кілька цікавих результатів. Завжди приємно бачити, що MegaETH виходить на перше місце : ) Щоб уявити дані в певному контексті, наскрізна затримка запиту RPC складається з трьох компонентів: (1) затримка поширення швидкості світла від/до спостерігача до/з сервера, (2) час, необхідний серверу для захоплення та подальшої обробки запитуваних даних, (3) час, необхідний спостерігачу, щоб завантажити відповідь. Як ви вже згадували, методи RPC, які тестуються, є легшими, як з точки зору обчислювальної вартості, так і з точки зору розміру даних. Це означає, що в експериментах в основному перевірялося (1), т. Е. Затримка поширення між спостерігачами і RPC-серверами. Не зрозумійте мене неправильно - RPC MegaETH також досить сильні на (2) і (3), і було б цікаво побачити експерименти, які їх напружують! Отже, як точно налаштувати затримку поширення? Власне, ручок не так вже й багато. По-перше, ми можемо розгорнути RPC-сервери в кількох географічних регіонах і автоматично спрямувати запит на найближчий сервер. Це схоже на те, як мережі швидкого харчування відкривають магазини всюди – поруч завжди є відділення! Точніше, наявність георозподілених серверів зменшує фізичну відстань між користувачами та серверами. По-друге, ми можемо оптимізувати топологію мережі. Навіть якщо він знаходиться між однією парою відправника та одержувача, затримка поширення залежить від фактичного пройденого мережевого шляху. Наприклад, між Східним узбережжям США та Азією затримка може змінюватися в 2 рази в залежності від того, чи проходять пакети даних через Тихий океан або через Європу. Іноді існує навіть кілька мережевих шляхів, що йдуть одним і тим же географічним маршрутом; Деякі з них більш перевантажені, ніж інші, що спричиняє більшу затримку. Це все одно, що мати кілька автомагістралей на вибір з пункту А в пункт Б. Переваги затримки, які ви спостерігали, швидше за все, виникли завдяки нашій оптимізації маршруту.

Офіційний RPC MegaETH проти Thirdweb RPC – затримка тестової мережі Я хотів отримати прямі дані з MegaEth без необхідності запускати будь-яку інфраструктуру, і шукав найшвидший спосіб зробити це. Я використовував "" для запуску простого бенчмарку, щоб побачити, як офіційний RPC MegaETH порівнюється зі стороннім RPC (Thirdweb). Мета полягала в тому, щоб перевірити, який з них швидше витягне свіжі дані з провідника з різних куточків світу. У тесті використовувався RPC-дзвінок «eth_blockNumber» і «eth_getBalance» в тестовій мережі MegaETH. Він охоплює 27 регіонів AWS на 6 континентах, надсилаючи запити один за одним з різницею в одну секунду. Він відстежував середню затримку, збої, 429 помилок, успішні запити та загальну тривалість запитів. Ось результати Всі результати показали, що офіційний MegaETH RPC був швидшим на всіх шести континентах і у всіх 27 регіонах. Згідно з цим тестом, затримка для MegaETH коливалася приблизно від 126 мс до 238 мс. Для Thirdweb затримка коливалася приблизно від 170 мс до 381 мс. Обидва мали низькі показники відмов, але у MegaETH їх було трохи менше, а загальна тривалість запиту була стабільно нижчою для MegaETH. Для контексту, зазвичай мережі мають принаймні кілька регіонів, де сторонній RPC працює швидше. Avalanche, Optimism та Ethereum мають приклади цього в публічних бенчмарках. Дивись - Результати Avalanche C-Chain - Оптимізм результатів - Результати Ethereum Перемога MegaETH над Thirdweb скрізь не є типовою. Моя теза про те, чому MegaETH Official rpc виходить на перше місце, полягає в тому, що мережа добре налаштована архітектурно і використовує один секвенсор за раз. Я запрошую @NamikMuduroglu @yangl1996 @0xSami_M поділитися своїми думками Це тестова мережа, тому цифри можуть змінюватися в основній мережі, коли трафік інтенсивніший. Однак на даний момент, якщо вам потрібен найшвидший і надійний спосіб отримання даних з провідника MegaETH, офіційний RPC є очевидним вибором. NB: Я не експерт, це лише теоретично і може бути не на 100% точним, оскільки тестовані дані були легкими дзвінками, також ці результати були зроблені миттєво, результати можуть відрізнятися, якщо задіяні більші дані в різний час, нарешті, я використовував публічний RPC ThirdWeb, можуть бути й інші, швидші.

12,78K

Найкращі

Рейтинг

Вибране