Questi sono alcuni risultati interessanti. È sempre bello vedere MegaETH in cima : ) Per contestualizzare i dati, la latenza end-to-end di una richiesta RPC è composta da tre componenti: (1) la latenza di propagazione della velocità della luce da/per l'osservatore al/server, (2) il tempo necessario al server per acquisire e post-elaborare i dati richiesti, (3) il tempo necessario all'osservatore per scaricare la risposta. Come hai menzionato, i metodi RPC testati sono più leggeri, sia in termini di costo computazionale che di dimensione dei dati. Questo significa che gli esperimenti hanno principalmente testato (1), cioè la latenza di propagazione tra gli osservatori e i server RPC. Non fraintendermi: gli RPC di MegaETH sono anche piuttosto forti su (2) e (3) e sarebbe interessante vedere esperimenti che li mettano alla prova! Quindi, come possiamo ottimizzare la latenza di propagazione? In realtà, non ci sono molte leve. Prima di tutto, possiamo distribuire i server RPC in più regioni geografiche e instradare automaticamente le richieste al server più vicino. È come se le catene di fast food aprissero negozi ovunque: c'è sempre un ramo nelle vicinanze! Più precisamente, avere server geo-distribuiti riduce la distanza fisica tra utenti e server. In secondo luogo, possiamo ottimizzare la topologia di rete. Anche se si tratta della stessa coppia di mittente e destinatario, la latenza di propagazione varia in base al percorso di rete effettivamente percorso. Ad esempio, tra la costa est degli Stati Uniti e l'Asia, la latenza può variare di 2x a seconda che i pacchetti di dati passino attraverso il Pacifico o attraverso l'Europa. A volte, ci sono anche più percorsi di rete che seguono la stessa rotta geografica; alcuni sono più congestionati di altri, il che induce una latenza più alta. È come avere più autostrade tra il punto A e il punto B. I vantaggi di latenza che hai osservato sono probabilmente derivati dall'ottimizzazione del percorso da parte nostra.
Avaworld
Avaworld15 ago, 21:38
MegaETH Official RPC vs Thirdweb RPC – Latenza del Testnet Volevo estrarre dati direttamente da MegaEth senza dover gestire alcuna infrastruttura e stavo cercando il modo più veloce per farlo. Ho utilizzato "" per eseguire un semplice benchmark per vedere come l'RPC ufficiale di MegaETH si confronta con un RPC di terze parti (Thirdweb). L'obiettivo era verificare quale dei due avrebbe estratto dati freschi dall'explorer più velocemente da diverse parti del mondo. Il test ha utilizzato la chiamata RPC `eth_blockNumber` e `eth_getBalance` sulla testnet di MegaETH. Ha colpito 27 regioni AWS in 6 continenti, inviando richieste una dopo l'altra con un intervallo di un secondo. Ha tracciato la latenza media, i fallimenti, gli errori 429, le richieste riuscite e la durata totale delle richieste. Ecco i risultati Tutti i risultati hanno mostrato che l'RPC ufficiale di MegaETH era più veloce in tutti e sei i continenti e in tutte le 27 regioni. La latenza per MegaETH variava da circa 126 ms a 238 ms secondo questo test. Per Thirdweb, la latenza variava da circa 170 ms a 381 ms. Entrambi avevano tassi di fallimento bassi, ma MegaETH ne aveva leggermente meno, e la durata totale delle richieste era costantemente inferiore per MegaETH. Per contesto, tipicamente le reti hanno almeno alcune regioni in cui un RPC di terze parti è più veloce. Avalanche, Optimism ed Ethereum hanno tutti esempi di questo in benchmark pubblici. Vedi i - Risultati di Avalanche C-Chain - Risultati di Optimism - Risultati di Ethereum MegaETH che supera Thirdweb ovunque non è tipico. La mia tesi sul perché l'RPC ufficiale di MegaETH risulti il migliore è che la rete è ben sintonizzata architettonicamente e utilizza un singolo sequencer alla volta. Invito @NamikMuduroglu @yangl1996 @0xSami_M a condividere i loro pensieri Questo è un testnet, quindi i numeri potrebbero cambiare su mainnet quando il traffico è più intenso. Tuttavia, per ora, se hai bisogno del modo più veloce e affidabile per estrarre dati dall'explorer di MegaETH, l'RPC ufficiale è la scelta chiara. NB: Non sono un esperto, questo è solo teorico e potrebbe non essere 100% accurato poiché i dati testati erano chiamate leggere, inoltre questi risultati sono stati snapshot, i risultati potrebbero variare se sono coinvolti dati più grandi in momenti diversi, infine ho utilizzato un RPC pubblico di thirdweb, potrebbero esserci altri più veloci.
12,74K