Acestea sunt câteva rezultate interesante. Este întotdeauna plăcut să vezi că MegaETH este pe primul loc :) Pentru a pune datele într-un anumit context, latența end-to-end a unei cereri RPC constă din trei componente: (1) latența de propagare a vitezei luminii de la/către observator la/de la server, (2) timpul necesar serverului pentru a prelua și postprocesa datele solicitate, (3) timpul necesar observatorului pentru a descărca răspunsul. După cum ați menționat, metodele RPC testate sunt mai ușoare, atât în ceea ce privește costul de calcul, cât și în ceea ce privește dimensiunea datelor. Aceasta înseamnă că experimentele au fost testate în principal (1), adică latența de propagare între observatori și serverele RPC. Nu mă înțelegeți greșit – RPC-urile MegaETH sunt, de asemenea, destul de puternice pe (2) și (3) și ar fi interesant să vedem experimente care să le streseze! Deci, cum reglam fin latența de propagare? De fapt, nu sunt prea multe butoane. În primul rând, putem implementa servere RPC în mai multe regiuni geografice și putem direcționa automat cererea către cel mai apropiat server. Este ca și cum lanțurile de fast-food deschid magazine peste tot – există întotdeauna o sucursală în apropiere! Mai exact, a avea servere geo-distribuite reduce distanța fizică dintre utilizatori și servere. În al doilea rând, putem optimiza topologia rețelei. Chiar dacă este între aceeași pereche de emițător și receptor, latența de propagare variază în funcție de calea reală a rețelei parcursă. De exemplu, între Coasta de Est a SUA și Asia, latența poate varia de 2 ori în funcție de faptul că pachetele de date trec prin Pacific sau prin Europa. Uneori, există chiar mai multe căi de rețea care urmează aceeași rută geografică; unele sunt mai congestionate decât altele, ceea ce induce o latență mai mare. Este ca și cum ai avea mai multe autostrăzi de ales din punctul A în punctul B. Avantajele de latență pe care le-ați observat cel mai probabil au venit din optimizarea rutei.
Avaworld
Avaworld15 aug., 21:38
RPC oficial MegaETH vs RPC Thirdweb – Latența rețelei de testare Am vrut să extrag date directe de la MegaEth fără a fi nevoie să rulez infrastructură și am căutat cea mai rapidă modalitate de a face acest lucru. Am folosit "" pentru a rula un benchmark simplu pentru a vedea cum se compară RPC-ul oficial al MegaETH cu un RPC terță parte (Thirdweb). Scopul a fost de a verifica care dintre ele ar extrage mai repede date proaspete de la explorator din diferite părți ale lumii. Testul a folosit apelul RPC "eth_blockNumber" și "eth_getBalance" pe rețeaua de testare MegaETH. Atinge 27 de regiuni AWS pe 6 continente, trimițând solicitări una după alta cu un decalaj de o secundă. A urmărit latența medie, eșecurile, 429 de erori, cererile reușite și durata totală a solicitării. Iată rezultatele Toate rezultatele au arătat că RPC-ul oficial MegaETH a fost mai rapid pe toate cele șase continente și în toate cele 27 de regiuni. Latența pentru MegaETH a variat de la aproximativ 126 ms la 238 ms conform acestui test. Pentru Thirdweb, latența a variat de la aproximativ 170 ms la 381 ms. Ambele au avut rate scăzute de eșec, dar MegaETH a avut puțin mai puține, iar durata totală a solicitării a fost în mod constant mai mică pentru MegaETH. Pentru context, de obicei rețelele au cel puțin câteva regiuni în care un RPC terță parte este mai rapid. Avalanche, Optimism și Ethereum au toate exemple în acest sens în benchmark-urile publice. Vezi - Rezultate Avalanche C-Chain - Rezultate optimisme - Rezultatele Ethereum MegaETH învingând Thirdweb peste tot nu este tipic. Teza mea despre motivul pentru care MegaETH Official rpc iese pe primul loc este că rețeaua este bine reglată arhitectural și folosește un singur secvențiator la un moment dat. @NamikMuduroglu @yangl1996 @0xSami_M invit să-și împărtășească gândurile Acesta este testnet, astfel încât numerele s-ar putea schimba pe mainnet atunci când traficul este mai intens. Cu toate acestea, deocamdată, dacă aveți nevoie de cel mai rapid și mai fiabil mod de a extrage date din exploratorul MegaETH, RPC-ul oficial este alegerea clară. NB: Nu sunt un expert, este doar teoretic și s-ar putea să nu fie 100% precis, deoarece datele testate au fost apeluri ușoare, de asemenea, aceste rezultate au fost instantaneate, rezultatele pot varia dacă sunt implicate date mai mari în momente diferite, în cele din urmă am folosit un rpc public thirdweb, ar putea exista și altele mai rapide.
12,8K