To jsou některé zajímavé výsledky. Je vždy příjemné vidět, že MegaETH je na vrcholu :) Abychom data zasadili do určitého kontextu, celková latence požadavku RPC se skládá ze tří komponent: (1) latence rychlosti šíření světla z/na pozorovatele do/ze serveru, (2) doba, kterou server potřebuje k získání a postprocesnímu zpracování požadovaných dat, (3) doba, kterou pozorovatel potřebuje ke stažení odpovědi. Jak jste zmínil, testované metody RPC jsou na lehčí straně, a to jak z hlediska výpočetní náročnosti, tak z hlediska velikosti dat. To znamená, že experimenty byly převážně testovány (1), tj. latence šíření mezi pozorovateli a RPC servery. Nechápejte mě špatně – RPC MegaETH jsou také docela silné na (2) a (3) a bylo by zajímavé vidět experimenty, které je zatěžují! Jak tedy vyladíme latenci šíření? Ve skutečnosti zde není příliš mnoho knoflíků. Za prvé, můžeme nasadit servery RPC ve více geografických oblastech a automaticky směrovat požadavky na nejbližší server. Je to jako řetězce rychlého občerstvení, které otevírají obchody všude – poblíž je vždy pobočka! Přesněji řečeno, geograficky distribuované servery snižují fyzickou vzdálenost mezi uživateli a servery. Za druhé, můžeme optimalizovat topologii sítě. I když se jedná o stejnou dvojici odesílatele a příjemce, latence šíření se liší v závislosti na skutečné projeté síťové cestě. Například mezi východním pobřežím USA a Asií se latence může lišit 2x v závislosti na tom, zda datové pakety procházejí Tichomořím nebo Evropou. Někdy dokonce existuje více síťových cest sledujících stejnou geografickou trasu; Některé jsou více přetížené než jiné, což vyvolává vyšší latenci. Je to jako mít na výběr z více dálnic z bodu A do bodu B. Výhody latence, které jste pozorovali, s největší pravděpodobností pocházely z naší optimalizace trasy.
Avaworld
Avaworld15. 8. 21:38
Oficiální RPC MegaETH vs Thirdweb RPC – latence testovací sítě Chtěl jsem získat přímá data z MegaEthu, aniž bych musel spouštět jakoukoli infrastrukturu, a hledal jsem nejrychlejší způsob, jak to udělat. Pomocí příkazu "" jsem spustil jednoduchý benchmark, abych zjistil, jak si oficiální RPC MegaETH stojí ve srovnání s RPC třetí strany (Thirdweb). Cílem bylo ověřit, který z nich by z nich rychleji vytáhl čerstvá data z průzkumníka z různých částí světa. Test používal volání RPC "eth_blockNumber" a "eth_getBalance" na testovací síti MegaETH. Zasahuje 27 regionů AWS na 6 kontinentech a odesílá požadavky jeden za druhým s jednosekundovou mezerou. Sledoval průměrnou latenci, selhání, 429 chyb, úspěšné požadavky a celkovou dobu trvání požadavku. Zde jsou výsledky Všechny výsledky ukázaly, že oficiální MegaETH RPC byl rychlejší na všech šesti kontinentech a ve všech 27 regionech. Latence pro MegaETH se podle tohoto testu pohybovala od přibližně 126 ms do 238 ms. U Thirdwebu se latence pohybovala od 170 ms do 381 ms. Oba měly nízkou poruchovost, ale MegaETH jich měl o něco méně a celková doba trvání požadavku byla u MegaETH trvale nižší. Pro kontext, sítě obvykle mají alespoň několik oblastí, kde je vzdálené volání procedur třetích stran rychlejší. Avalanche, Optimism a Ethereum mají příklady ve veřejných srovnávacích testech. Viz - Výsledky Avalanche C-Chain - Výsledky optimismu - Výsledky Etherea MegaETH porážet Thirdweb všude není typické. Moje teze o tom, proč je MegaETH Official rpc na prvním místě, je, že síť je architektonicky dobře vyladěná a používá vždy jen jeden sekvencer. Vyzývám @NamikMuduroglu @yangl1996 @0xSami_M, aby se podělili o své myšlenky Jedná se o testovací síť, takže čísla se mohou na mainnetu posunout, když je provoz silnější. Prozatím však, pokud potřebujete nejrychlejší a nejspolehlivější způsob, jak získat data z průzkumníka MegaETH, je oficiální RPC jasnou volbou. Poznámka: Nejsem odborník, je to jen teoretické a nemusí být 100% přesné, protože testovaná data byla odlehčená volání, také tyto výsledky byly snímkovány, výsledky se mohou lišit, pokud se jedná o větší data v různých časech, naposledy jsem použil veřejný thirdweb rpc, mohly by být i jiné, rychlejší.
12,14K