Sunnysiden 7/14 PeerDAS Devnet -raportti on täällä! Sukellaan PeerDASin nykytilaan - kuinka paljon möykkyä pystymme käsittelemään ja mikä on pullonkaula?

Näiden ponnistelujen joukossa Sunnysiden rooli on ajaa viikoittaisia devnettejä monissa eri kokoonpanoissa ja syöttää ydinkehittäjille tuloksena olevia oivalluksia: •Missä nykyiset PeerDAS-rajat ovat •Mitkä komponentit aiheuttavat pullonkauloja •Kuinka hyvin optimoinnit, kuten Supernodes ja GetBlobV2, toimivat käytännössä

Päätavoitteenamme on testata nopeasti ja joustavasti tavoilla, jotka täydentävät sitä, mitä muut tiimit, kuten @ethPandaOps tekevät fusaka-deventsissä, ja antaa oikea-aikaista palautetta, joka tukee PeerDASin jatkuvaa käyttöönottoa.

Tällä viikolla käytimme 12 devnetiä ja suoritimme 3 testipakettia käyttäen @ethPandaOps uusinta fusaka-devnet-2-kuvaa: 1.Blob-siirtonopeus (blob-objektien enimmäismäärä lohkoa kohti) 2. Verkon kaistanleveys (jatkuvan kuormituksen testi) 3. Kaistanleveyden rajoitus (30 / 20 / 10 Mbps ylärajat)

1 – Blobin suorituskykytesti Testitulokset osoittivat, että useimmat CL-asiakkaat pystyivät käsittelemään 84 blobia lohkoa kohden tai enemmän ja pysyivät vakaina vähintään 40 blobilla. Jotkut asiakkaat kirjasivat suhteellisen pienemmän blob-blob-määrän verrattuna aikaisempiin devnetteihin - mutta tämä voi johtua siitä, että validoijien määrä solmua kohden tässä devnetissä väheni 100:sta 8:aan, mikä puolestaan alensi kunkin solmun aliverkon osallistumisastetta.

2 – Verkon kaistanleveyden testi Toisin kuin aikaisemmissa devnet-verkoissa, joissa verkko muuttui usein epävakaaksi suurilla blob-määrillä, tällä kertaa kaikki devnetit toimivat vakaasti pitkän aikaa (~16 tuntia), vaikka lohkoa kohden olisi 60 tai 72 blobia. Vaikka tämä ei takaa tuotantotason vakautta, se osoittaa, että ainakin jotkut CL-EL-yhdistelmät ovat saavuttaneet paljon korkeamman kestävyyden optimoinnin 🚀 avulla

3 – Kaistanleveyden rajoitustesti Tarkistaakseen, voivatko todelliset kotisijoittajat osallistua sujuvasti, kun PeerDAS on aktiivinen, tässä testissä käytettiin verkkorajoituksia ja tutkittiin, mitkä tekijät tulevat pullonkauloiksi erilaisissa rajoitetuissa skenaarioissa. Useissa testeissä havaitsimme, että solmun kaistanleveyden käyttö kasvaa ajoittain - erityisesti lähellä paikan alkua, kun möykkyjä juoruillaan - ja että nämä piikit rajoittavat verkon yleistä suorituskykyä. Burst-liikenne tapahtui tasaisesti solmujen välillä sen sijaan, että se olisi aiheutunut tietystä CL- tai EL-asiakkaasta, ja kun purskeet alkoivat, verkko ei pystynyt lisäämään blobin suorituskykyä enempää. Toisin sanoen purskeliikenne on suurin pullonkaula kaistanleveyden rajoittamissa ympäristöissä, ja meidän on löydettävä tapoja lieventää sitä.

Lisäksi kommunikoimme eri asiakastiimien kanssa ja kannustimme parantamaan synkronointia ja vertaisongelmia.

Sunnyside devnet on edelleen käynnissä 🏗️; Interop-devnetien suorittaminen useiden asiakasyhdistelmien, yksityiskohtaisempien kaistanleveystestien, normaalit tapahtumat sisältävät roskapostitestien ja takaisintäyttö-/synkronointitestien avulla pullonkaulojen tunnistamiseksi ympäristöissä, jotka muistuttavat enemmän pääverkon olosuhteita.