Popularne tematy
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
To są interesujące wyniki. Zawsze miło widzieć, że MegaETH jest na szczycie : )
Aby umieścić dane w kontekście, opóźnienie end-to-end żądania RPC składa się z trzech komponentów: (1) opóźnienie propagacji prędkości światła od/do obserwatora do/z serwera, (2) czas, jaki zajmuje serwerowi pobranie i przetworzenie żądanych danych, (3) czas, jaki zajmuje obserwatorowi pobranie odpowiedzi. Jak wspomniałeś, testowane metody RPC są lżejsze, zarówno pod względem kosztów obliczeniowych, jak i rozmiaru danych. Oznacza to, że eksperymenty głównie testowały (1), tj. opóźnienie propagacji między obserwatorami a serwerami RPC. Nie zrozum mnie źle – RPC MegaETH są również dość mocne w (2) i (3) i byłoby interesujące zobaczyć eksperymenty, które je obciążają!
Jak więc możemy dostroić opóźnienie propagacji? Właściwie nie ma zbyt wielu pokręteł. Po pierwsze, możemy wdrożyć serwery RPC w wielu regionach geograficznych i automatycznie kierować żądania do najbliższego serwera. To jak sieci fast food otwierające lokale wszędzie – zawsze jest jakaś placówka w pobliżu! Dokładniej mówiąc, posiadanie serwerów rozproszonych geograficznie zmniejsza fizyczną odległość między użytkownikami a serwerami.
Po drugie, możemy zoptymalizować topologię sieci. Nawet jeśli jest to między tą samą parą nadawcy i odbiorcy, opóźnienie propagacji różni się w zależności od rzeczywistej ścieżki sieciowej. Na przykład, między wschodnim wybrzeżem USA a Azją, opóźnienie może się różnić o 2x w zależności od tego, czy pakiety danych przechodzą przez Pacyfik, czy przez Europę. Czasami istnieje nawet wiele ścieżek sieciowych podążających tą samą trasą geograficzną; niektóre są bardziej zatłoczone niż inne, co powoduje wyższe opóźnienie. To jak posiadanie wielu autostrad do wyboru z punktu A do punktu B. Korzyści z opóźnienia, które zaobserwowałeś, najprawdopodobniej pochodziły od nas, optymalizujących trasę.
15 sie, 21:38
MegaETH Oficjalne RPC vs Thirdweb RPC – Latencja Testnetu
Chciałem pobrać dane bezpośrednio z MegaEth, nie uruchamiając żadnej infrastruktury i szukałem najszybszego sposobu, aby to zrobić.
Użyłem "" do przeprowadzenia prostego benchmarku, aby zobaczyć, jak oficjalne RPC MegaETH porównuje się z RPC zewnętrznego (Thirdweb). Celem było sprawdzenie, które z nich szybciej pobierze świeże dane z eksploratora z różnych części świata.
Test wykorzystał wywołania RPC `eth_blockNumber` i `eth_getBalance` na testnecie MegaETH. Obejmuje 27 regionów AWS na 6 kontynentach, wysyłając żądania jedno po drugim z jednosekundową przerwą. Śledził średnią latencję, błędy, błędy 429, udane żądania i całkowity czas trwania żądania.
Oto wyniki
Wszystkie wyniki pokazały, że oficjalne RPC MegaETH było szybsze na wszystkich sześciu kontynentach i we wszystkich 27 regionach. Latencja dla MegaETH wahała się od około 126 ms do 238 ms według tego testu. Dla Thirdweb latencja wahała się od około 170 ms do 381 ms. Oba miały niskie wskaźniki błędów, ale MegaETH miało ich nieco mniej, a całkowity czas trwania żądania był konsekwentnie niższy dla MegaETH.
Dla kontekstu, typowo sieci mają przynajmniej kilka regionów, gdzie RPC zewnętrznego jest szybsze. Avalanche, Optimism i Ethereum mają przykłady tego w publicznych benchmarkach. Zobacz
- Wyniki Avalanche C-Chain
- Wyniki Optimism
- Wyniki Ethereum
MegaETH wygrywające z Thirdweb wszędzie nie jest typowe.
Moja teza na temat tego, dlaczego MegaETH Oficjalne RPC wypada najlepiej, to że sieć jest dobrze dostrojona architektonicznie i używa jednego sekwencera w danym czasie.
Zachęcam @NamikMuduroglu @yangl1996 @0xSami_M do podzielenia się swoimi przemyśleniami
To jest testnet, więc liczby mogą się zmienić na mainnecie, gdy ruch będzie większy. Jednak na razie, jeśli potrzebujesz najszybszego i najbardziej niezawodnego sposobu na pobranie danych z eksploratora MegaETH, oficjalne RPC jest wyraźnym wyborem.
NB: Nie jestem ekspertem, to tylko teoretyczne i może nie być w 100% dokładne, ponieważ testowane dane były lekkimi wywołaniami, a także te wyniki były zrzutem, wyniki mogą się różnić, jeśli zaangażowane są większe dane w różnych momentach, wreszcie użyłem publicznego RPC Thirdweb, mogą być inne szybsze.
12,55K
Najlepsze
Ranking
Ulubione