Suorituskykymittaukset: vertaisyhteys halki Euroopan

Pariisissa oleva laite säilyttää tiedostot. Amsterdamissa ja Varsovassa olevat laitteet liittyvät holviin tyhjällä kansiolla ja lataavat kaiken: kerran suoraan Pariisin laitteelta ja toisiltaan (vertaisyhteydellä) ja kerran Pariisissa sijaitsevasta S3-bucketista. Mitattu 9. ja 10. lokakuuta 2026 vuokratuilla pilvikoneilla.

Tämä sivu kertoo, mitä mitattiin, miten, mikä tuloksia rajoitti ja mitä Varstossa muutettiin niiden vuoksi. Jokaisella suunnitellulla tapauksella on nyt lukemat, kustakin kaksi ajoa, ellei taulukossa toisin mainita. Luvut koskevat alfaversiota: ne kuvaavat koodia sellaisena kuin se oli noina päivinä. Versiosta 0.0.1-alpha.11 lähtien suuret tiedostot pilkotaan suurempiin lohkoihin (keskimäärin 1 MiB 32 MiB:n tiedostoista alkaen, 4 MiB 1 GiB:n tiedostoista alkaen), joten tämän sivun lohkomäärät eivät enää päde niihin. Mittausohjelma on repositoriossa hakemistossa scripts/bench/, ja tiivistetyt tulokset on julkaistu JSON-muodossa, joten jokaisen sivun luvun voi tarkistaa ja ajon toistaa.

Yhteenveto

• Kotiliittymältä NATin takaa (100 Mbit/s): kaikki 14 siirtoa kotitietokoneen ja Amsterdamin ja Varsovan palvelinten välillä tulivat pelkästään vertaisilta: kotireitittimen NATin läpi, NATista NATiin ja symmetrisen NATin läpi välittäjän kautta. Suuret tiedostot kulkivat 8.0–9.3 MB/s, 1.3–1.8 kertaa niin nopeasti kuin sama lataus bucketista samalla liittymällä. Lisätiedot.
• Paljon pieniä tiedostoja, Pariisista Amsterdamiin (9 ms:n päähän): 10 000 tiedostoa tuli vertaisyhteydellä 111 sekunnissa (90 tiedostoa/s) ja bucketista 299 sekunnissa (34 tiedostoa/s): vertaisyhteys oli 2.7 kertaa nopeampi. Varsovaan (33 ms:n päähän) ero oli pieni: 260 s ja 294 s. Bucketin nopeus kuitenkin vaihteli kellonajan mukaan: kolme tuntia myöhemmin, kahden lukijan ladatessa yhtä aikaa, se toimitti Amsterdamiin 64 tiedostoa/s ja Varsovaan 53, lähes yhtä paljon kuin vertaisyhteys kahdella lukijalla (70 ja 39).
• Suuret tiedostot: Amsterdamiin 4 GiB vertaisyhteydellä 159 sekunnissa (27.0 MB/s) ja bucketista 180 sekunnissa (23.9 MB/s), ja vertaisyhteys oli paljon tasaisempi. Varsovaan bucket oli nopeampi: 190 s (23.4 MB/s) ja vertaisyhteydellä 423 s (10.2 MB/s). Vertaisyhteys avaa jokaista lohkoa varten uuden TCP-yhteyden, mikä maksaa edestakaisia viiveitä, sitä enemmän mitä pidempi matka on.
• Kaksi lukijaa yhtä aikaa vertaisyhteydellä: lukijat auttavat toisiaan. Varsova sai 69 % lohkoistaan Amsterdamilta, jolla ne jo olivat, ja vain 31 % Pariisista, joten Pariisin laite lähetti 8.6 GB:n sijaan 5.6 GB. Kumpikaan lukija ei hidastunut.
• Pakkautuva teksti: bucket oli hieman nopeampi Amsterdamiin (18.1 vs. 16.7 MB/s) ja yli kaksi kertaa nopeampi Varsovaan (16.7 vs. 7.3 MB/s). Tekstiä jakava laite pakkaa jokaisen lohkon uudelleen jokaista pyyntöä varten tasolla, joka on valittu pientä tallennuskokoa eikä nopeutta silmällä pitäen.
• Jokainen vertaisajojen lohko tuli vertaiselta: 202 544 lohkoa 202 544:stä 24 mitatussa latauksessa, ei yhtäkään bucketista, josta lohkot oli poistettu; jokainen tiedosto vastasi jälkikäteen SHA-256-tiivistettään.
• Ajot paljastivat ja korjasivat yhdeksän ongelmaa, muun muassa lataukset, jotka hakivat yhden lohkon kerrallaan (nyt kahdeksan matkalla yhtä aikaa, ja pieniä tiedostoja haetaan ennakkoon tiedostojen yli), sekä vertaispalvelimen, joka vastasi yhteen pyyntöön kerrallaan. QUICin asettamista ensisijaiseksi reitiksi internetin yli kokeiltiin, se mitattiin tässä hitaammaksi, ja muutos peruttiin. Lisätiedot ja luvut.

Kotoa NATin takaa (10. lokakuuta)

Yllä olevat ajot ovat julkisilla osoitteilla varustettujen datakeskusten välillä. Nämä ovat kotoa: pöytäkone 100 Mbit/s:n kuluttajaliittymällä reitittimensä NATin takana, ja Varsto asennettuna niin kuin käyttäjä sen asentaa (Linux-paketti, käyttäjän taustapalvelu). Siihen liittyi kaksi pilvikonetta: yksi Amsterdamissa julkisella osoitteella ja yksi Varsovassa, jossa oli kaksi laitetta verkkonimiavaruuksissa NATin takana, toinen kartio-NATin takana (Linuxin MASQUERADE säilyttää portin) ja toinen symmetrisen NATin takana (MASQUERADE satunnaisilla porteilla, mikä estää reiänlyönnin). Kuten edellä, Pariisin bucketissa oli vain kirjanpito ja tiedostoluettelot: sen lohkot poistettiin ennen jokaista noutoa, joten jokaisen lohkon piti tulla vertaiselta, ja jokainen tiedosto tarkistettiin SHA-256-tiivistettään vasten. Mittausohjelma on scripts/nat-test/home-nat.py.

Liittymä

Kotitietokone ja	Edestakainen viive	TCP, yksi virta, kotiin	TCP, yksi virta, kotoa
Amsterdam	31 ms	9.1 MB/s	12.1 MB/s
Varsova	21 ms	10.6 MB/s	11.9 MB/s
Bucket (Pariisi), rclone, 256 MiB	–	7.5 MB/s	4.3 MB/s

100 Mbit/s on enintään 12.5 MB/s, joten se on katto kaikelle tällä liittymällä.

NATien läpi

STUN luokitteli kotireitittimen kartio-NATiksi. Kukin siirto siirsi yhden 64 MiB:n satunnaisista tavuista koostuvan tiedoston; tässä koossa synkronoinnin kiinteä kustannus (kirjanpito ja tiedostoluettelo bucketissa) on suuri osa ajasta.

Mistä	Mihin	Vastaanottajan käyttämä reitti	Aika	Nopeus
Koti	Amsterdam (julkinen)	suora, kodin NATin sisään	12.2 s	5.5 MB/s
Amsterdam	Koti	suora	14.3 s	4.7 MB/s
Varsova, kartio-NAT	Koti	suora, NATista NATiin (reiänlyönti)	13.3 s	5.0 MB/s
Koti	Varsova, kartio-NAT	suora, NATista NATiin	14.5 s	4.6 MB/s
Varsova, symmetrinen NAT	Koti	välitetty Amsterdamin kautta	65.7 s	1.0 MB/s
Koti	Varsova, symmetrinen NAT	välitetty Amsterdamin kautta	65.3 s	1.0 MB/s

Jokainen reitti toimi suunnitellusti: suoraan, kun NAT säilyttää osoitemuunnoksensa, ja välittäjän kautta jonkin käyttäjän oman tavoitettavan laitteen kautta, kun ei säilytä. Mitään valmistajan palvelinta ei tarvittu; laitteet löysivät toisensa bucketissa olevien tietueiden ja julkisten STUN-palvelinten avulla.

Suuret tiedostot

Yksi 512 MiB:n satunnaisista tavuista koostuva tiedosto siirtoa kohden, pelkällä vertaisyhteydellä. Ensimmäinen sarake on versio 0.0.1-alpha.9 alla kuvatulla välittäjäkorjauksella; toisessa ovat mukana saman päivän latausmuutokset (yhteydet pidetään auki vertaiskohtaisesti, objektit lähetetään pakkaamatta niitä uudelleen ja ikkuna mukautuu 8 ja 32 lohkon välillä).

Siirto	Ennen muutoksia	Muutosten kanssa	Osuus yhdestä TCP-virrasta	Osuus 100 Mbit/s:sta
Amsterdam → koti	4.7 MB/s	8.0 MB/s	88 %	64 %
Varsova (kartio-NAT) → koti	6.9 MB/s	9.3 MB/s	88 %	74 %
Koti → Amsterdam	8.7 MB/s	9.3 MB/s	77 %	74 %
Koti → Varsova (kartio-NAT)	–	8.6 MB/s	72 %	69 %

Sama lataus bucketista

Toinen laite kotitietokoneella, vertaisyhteys pois päältä, nouti saman liittymän kautta 512 MiB:n tiedoston, jonka palvelin oli juuri lähettänyt bucketiin.

Kirjoittaja	Bucketista	Vertaisyhteydellä (yllä)	Vertaisyhteys oli
Amsterdam	6.1 MB/s	8.0 MB/s	1.3 kertaa niin nopea
Varsova (kartio-NAT)	5.2 MB/s	9.3 MB/s	1.8 kertaa niin nopea

Datakeskusten välillä bucket pysyy mukana, koska bucket ja koneet ovat samassa nopeassa runkoverkossa. Kotoa katsottuna bucket on yksi kaukainen välietappi lisää omine pyyntökohtaisine kustannuksineen, kun taas vertainen lähettää suoraan liittymää pitkin.

Löydetty ja korjattu

• Välittäjä ei tavoittanut laitetta, jota se välittää. Symmetrisen NATin takana oleva laite pitää yhteyttä auki johonkin holvin tavoitettavaan laitteeseen, ja muut laitteet tavoittavat sen tämän välittäjän kautta. Välittäjällä itsellään ei ollut reittiä siihen: se ei välittänyt itsensä kautta ja yritti yhä uudelleen osoitteita, joihin kukaan ei voi yhdistää. Nyt se kysyy tällaiselta laitteelta sen yhteyden kautta, jota laite pitää sen kanssa auki.
• Vertaislataukset lähes liittymän nopeudella. Yllä kuvatut muutokset suunnilleen kaksinkertaistivat latauksen Amsterdamista kotiin (4.7:stä 8.0 MB/s:iin).

Yhä hidasta

• Välitetty reitti kuljetti vain 1–1.6 MB/s: jokainen lohko kulkee omana pyyntönään kahden välietapin kautta, kotoa Amsterdamiin Varsovaan ja takaisin. Se on varareitti vaikeimmille NATeille, mutta sen pitäisi silti täyttää liittymästä suurempi osa.
• Pienet siirrot maksavat kiinteän kustannuksen bucketissa olevasta kirjanpidosta ja tiedostoluettelosta: 64 MiB vei 12–15 s, kun pelkät tavut vaativat noin 7.
• Palvelun rajapinta saattoi odottaa vastausta minuutteja, kun synkronointi oli käynnissä ja yritti yhä uudelleen vertaista, jota se ei tavoittanut; tilakutsujen ei pitäisi odottaa synkronointia.

Rajoitukset: yksi kotiliittymä, yksi iltapäivä, yksi ajo tapausta kohden (Varsovasta kotiin toistettu ajo kuvakaappauksen aikana kulki 5.2 MB/s, ja Amsterdam oli hetken tavoittamattomissa); Varsovan NATit ovat Linuxin eivätkä kuluttajareitittimien; palvelimet olivat pieniä (Scaleway DEV1-M). Latausmuutokset ovat katselmoinnissa eikä niitä ole vielä julkaistu.

Mitä mitattiin

Aineisto	Bucketista (S3)	Vertaisyhteydellä
Suuret tiedostot (2 × 2 GiB)	Amsterdam, Varsova, molemmat yhtä aikaa (9.10.)	Amsterdam, Varsova (9.10.); molemmat yhtä aikaa (10.10.)
Paljon pieniä tiedostoja (10 000)	Amsterdam, Varsova, molemmat yhtä aikaa (10.10.; 9.10. ajot säilytetty nimellä ”ennen ennakkohakua”)	Amsterdam, Varsova, molemmat yhtä aikaa (10.10.)
Pakkautuva teksti (512 MiB)	Amsterdam, Varsova (9.10.); molemmat yhtä aikaa (10.10.)	Amsterdam, Varsova, molemmat yhtä aikaa (10.10.)
Kirjoittajan lähetys	2 ajoa aineistoa kohden, yksi kumpanakin päivänä	RAM-levy: 2 ajoa aineistoa kohden; paikallinen levy: 1 ajo aineistoa kohden

Kaksi ajoa tapausta kohden; taulukoiden ajat ovat niiden mediaani (kahden ajon keskiarvo), ja kummankin ajon aika on sen vieressä. Yksittäiset ajot on merkitty erikseen. Päivien välillä latauskoodi muuttui vain tavoilla, jotka eivät koske vertailtua tapausta: 9. lokakuuta suurten tiedostojen ja tekstin ajot hakevat tiedoston sisäiset lohkot täsmälleen kuten 10. lokakuuta koontiversio, ja paljon pieniä tiedostoja -tapauksen bucket-ajot toistettiin 10. lokakuuta, koska ennakkohaku tiedostojen yli on uusi. Kaksi viimeistä tapausta, pakkautuva teksti vertaisyhteydellä ja paljon pieniä tiedostoja bucketista, kumpikin kahdella lukijalla yhtä aikaa, ajettiin kolme tuntia muiden jälkeen uusilla koneilla yhdistetyllä koontiversiolla; bucket oli tuossa istunnossa selvästi nopeampi kuin aiemmassa.

Järjestelyt ja vertailutaso

• Koneet: kolme Scaleway POP2-4C-16G -instanssia (4 vCPU AMD EPYC 7543, 16 GB RAM, 80 GB:n verkkolohkotaltio, Ubuntu 24.04), luotu joka päivä uusina: kirjoittaja Pariisissa (fr-par-1), lukijat Amsterdamissa (nl-ams-1) ja Varsovassa (pl-waw-1). Jokaisella koneella oli julkinen IPv4-osoite omassa verkkoliitännässään, joten niiden välillä ei ollut NATia.
• Bucket: väliaikainen Scaleway Object Storage -bucket Pariisissa (fr-par), kirjoittajan alueella. Amsterdamin ja Varsovan lukijat lukivat sitä rajojen yli.
• Varsto: 0.0.1-alpha.8 alla luetelluilla korjauksilla, staattinen Linux-koontiversio (musl). 9. lokakuuta: commitit 37bee19:ään asti (bucket-ajot: 0180ca8, joka eroaa vain vertaispalvelimen ja tiedostovahdin osalta). 10. lokakuuta: commit 9b93263 vertaisajoissa; saman päivän aiemmissa bucket-ajoissa käytettiin versiota a3ba1c0, joka eroaa vain vertaisreittien järjestyksen osalta; viimeisinä ajetuissa kahdessa tapauksessa käytettiin yhdistettyä koontiversiota dc09721, joka on näiden ajojen kannalta sama koodi kuin 9b93263.
• Ajo: uusi laite liittyy holviin holviavaimella, käynnistää taustapalvelun, keskeyttää sen, liittää tyhjän kansion ja pyytää palvelua synkronoimaan kansion kerran (POST /api/sync). Aika mitataan pyynnöstä sen vastaukseen: tiedostoluettelo luetaan, jokainen lohko haetaan, tarkistetaan tiivistettään vasten, puretaan, tarkistetaan palan tunnistetta vasten ja kirjoitetaan. Lopuksi mittausohjelma vertaa kansion SHA-256-luetteloa kirjoittajan luetteloon. Sen jälkeen laite poistetaan taas. Automaattinen varmennus oli pois päältä kaikilla mittauslaitteilla, koska se lataa ja korjaa lohkoja taustalla.

Verkon vertailutaso

Välillä	Edestakainen viive (ping)	TCP, yksi virta (iperf3, Pariisi lähettää), 9.10. / 10.10.	TCP, neljä virtaa
Pariisi – Amsterdam	9.4 ms	925 / 958 Mbit/s	875 / 836 Mbit/s
Pariisi – Varsova	33.4 ms	738 / 777 Mbit/s	949 / 909 Mbit/s
Amsterdam – Varsova	20.6 ms	–	–

Lukija	S3: yksi 256 MiB:n objekti, yksi virta (rclone), 9.10. / 10.10.	S3: 4 KiB:n objekteja peräkkäin, 9.10. / 10.10.
Pariisi	91 / 59 MB/s	7 / 45 ms kukin
Amsterdam	26 / 21 MB/s	16 / 107 ms kukin
Varsova	52 / 15 MB/s	52 / 122 ms kukin

Koneiden väliset yhteydet kuljettivat yhdessä TCP-virrassa 700–950 Mbit/s (90–120 MB/s), eikä mikään Varston siirroista päässyt lähellekään: kaikkia rajoittivat edestakaiset viiveet ja pyyntökohtainen työ. Bucketin oma nopeus vaihteli paljon päivästä toiseen (toinen mittaus tehtiin varhain aamulla); sen ajot vaihtelivat koko ajan enemmän kuin vertaisajot.

Aineistot

• Suuret tiedostot: kaksi 2 GiB:n tiedostoa satunnaisia (pakkautumattomia) tavuja, yhteensä 4 GiB, noin 13 400 lohkoa.
• Paljon pieniä tiedostoja: 10 000 tiedostoa 500 hakemistossa, koot arvottu log-normaalijakaumasta, jonka mediaani on 16 KiB, rajattuna välille 1 KiB…256 KiB, joka kahdeskymmenes tiedosto toisen kopio; yhteensä 281 MiB. Samanmuotoinen 50 000 tiedoston aineisto lähetettiin, mutta sitä ei ladattu.
• Pakkautuva teksti: 128 tiedostoa, kukin 4 MiB generoituja verkkopalvelimen lokirivejä, yhteensä 512 MiB; zstd tallentaa ne 138 MiB:iin.

Mitä ”pelkkä vertaisyhteys” tarkoittaa

Varsto kysyy ensin vertaisilta ja vasta sitten tallennuspaikoilta, joten vertaismittauksessa on varmistettava, ettei bucket voi auttaa. Kun kirjoittaja oli lähettänyt tiedot ja bucket-ajot oli tehty, bucketista poistettiin kaikki objektit polun chunks/ alta. Bucketiin jäi se, mitä laitteet tarvitsevat löytääkseen toisensa ja tietääkseen, mitä on olemassa (allekirjoitettu kirjanpito, tiedostoluettelot, laite- ja vertaistietueet), mutta ei lainkaan tiedostojen sisältöä: lohko, jota mikään vertainen ei olisi pystynyt toimittamaan, olisi jättänyt tiedoston saavuttamattomiin. Sitten:

• kunkin ajon noutoraportti laski vertaisilta tulleet lohkot ja kaikki lohkot, ja mittausohjelma hylkäsi jokaisen ajon, jossa nämä erosivat;
• lukijoiden liikennelaskurit (/api/p2p/traffic) ja kirjoittajan laskurit täsmäsivät: yhdellä lukijalla lukija vastaanotti laitteelta writer-paris täsmälleen aineiston tallennetun koon ja kirjoittaja lähetti saman verran; kahdella lukijalla se, minkä kumpikin vastaanotti Pariisista ja toiselta lukijalta, oli yhteensä tallennettu koko, ja Pariisin laite lähetti loput;
• reitti oli jokaisessa ajossa suora, TCP:llä kirjoittajan julkiseen osoitteeseen porttiin 17893 (palvelun loki kertoo, mille reitille se asettui), ja kahden lukijan välillä molemmat yhtä aikaa -ajoissa. Välittäjää ei käytetty; lähiverkkoreitti oli mahdoton kolmen maan välillä.

Ajo	Ladattuja paloja	Vertaisilta	S3:sta	Reitti
tiedostot, Amsterdam, yksin (×2)	20 240	20 240	0	writer-paris: suora
tiedostot, Amsterdam, kaksi lukijaa (×2)	20 240	20 240	0	waw-p2p-files-ams+waw-1: suora, writer-paris: suora
tiedostot, Varsova, kaksi lukijaa (×2)	20 240	20 240	0	: suora, ams-p2p-files-ams+waw-2: , writer-paris: suora
tiedostot, Varsova, yksin (×2)	20 240	20 240	0	writer-paris: suora
suuret, Amsterdam, yksin (×2)	26 946	26 946	0	writer-paris: suora
suuret, Amsterdam, kaksi lukijaa (×2)	26 758	26 758	0	: suora, writer-paris: suora
suuret, Varsova, kaksi lukijaa (×2)	26 758	26 758	0	ams-p2p-large-ams+waw-1: suora, ams-p2p-large-ams+waw-2: suora, writer-paris: suora
suuret, Varsova, yksin (×2)	26 946	26 946	0	writer-paris: suora
teksti, Amsterdam, yksin (×2)	3 544	3 544	0	writer-paris: suora
teksti, Amsterdam, kaksi lukijaa (×2)	3 544	3 544	0	: suora, writer-paris: suora
teksti, Varsova, kaksi lukijaa (×2)	3 544	3 544	0	ams-p2p-text-ams+waw-1: suora, writer-paris: suora
teksti, Varsova, yksin (×2)	3 544	3 544	0	writer-paris: suora

Suuret tiedostot

4 GiB kahdessa tiedostossa, satunnaista sisältöä, joten zstd tallentaa sen sellaisenaan.

Vertaisyhteys (Pariisin kirjoittajalta) S3-bucket Pariisissa (MB/s, suurempi on parempi)

Lukija	Vertaisyhteys: aika	MB/s	S3: aika	MB/s	P2P vs. S3
Amsterdam, yksin	159 s (158 s / 161 s)	27.0	180 s (171 s / 190 s)	23.9	1.1× nopeampi
Varsova, yksin	423 s (420 s / 426 s)	10.2	190 s (155 s / 226 s)	23.4	2.2× hitaampi
Amsterdam, kaksi lukijaa	162 s (162 s / 161 s)	26.6	95 s (90 s / 101 s)	45.2	1.7× hitaampi
Varsova, kaksi lukijaa	365 s (367 s / 362 s)	11.8	208 s (185 s / 232 s)	20.9	1.8× hitaampi

Koontiversio	Lukija	Aika	MB/s
Vertaisyhteys, QUIC kokeiltu ennen TCP:tä (yksi yhteys vertaista kohden), 10. lokakuuta	Amsterdam, yksin	230 s (229 s / 230 s)	18.7
Vertaisyhteys, QUIC kokeiltu ennen TCP:tä (yksi yhteys vertaista kohden), 10. lokakuuta	Varsova, yksin	466 s (466 s)	9.2

Amsterdamiin, yhdeksän millisekunnin päähän, vertaisyhteys voitti bucketin niukasti ja oli paljon tasaisempi: jokainen vertaisajo kesti 158–162 s, bucketin ajot 171 s ja 190 s. Varsovaan bucket oli yli kaksi kertaa nopeampi. Jokainen noin 300 KiB:n lohko on yksi HTTP-pyyntö uudella TCP-yhteydellä: kättely ja sitten TCP:n hidas aloitus kymmenestä paketista, joten lohko vaatii useita edestakaisia matkoja, oli yhteys kuinka nopea tahansa. 33 ms:n viiveellä tämä rajaa kahdeksan samanaikaista pyyntöä noin 10 MB/s:iin, ja juuri sen verran mitattiin. Bucketin HTTPS-yhteydet pidetään auki pyyntöjen välillä.

Kun molemmat lukijat latasivat yhtä aikaa, Varsova sai 4.30 GB:stään 2.97 GB Amsterdamilta (20 ms:n päässä, lähempänä kuin Pariisi) ja vain 1.3 GB Pariisista; Amsterdam, jolla lohkot olivat ensin, jakoi niitä samalla kun latasi itse. Varsova oli jopa hieman nopeampi kuin yksin (11.8 vs. 10.2 MB/s) ja Amsterdam yhtä nopea kuin yksin. Myös bucket palveli kahta lukijaa yhtä aikaa hidastamatta kumpaakaan (45 ja 21 MB/s); se on jaettua infrastruktuuria, joka on rakennettu monille lukijoille.

Lukijan oma työ: noin 40 s prosessoriaikaa 4 GiB:lle (purku, kaksi tiivistettä lohkoa kohden, kirjoitus), enintään 490 MB muistia. Pariisin laite käytti 40 s prosessoriaikaa kunkin 4 GiB:n jakamiseen, yksi ydin noin neljänneksen kuormitettuna.

Paljon pieniä tiedostoja

10 000 tiedostoa, kooltaan 1 KiB – 256 KiB. Kukin tiedosto on yksi lohko. Lokakuun 10. päivästä lähtien nouto hakee enintään 32 tulevan tiedoston lohkot yhdessä, kahdeksan pyyntöä kerrallaan, ennen kuin kirjoittaa ne yksitellen.

Vertaisyhteys (Pariisin kirjoittajalta) S3-bucket Pariisissa (tiedostoa/s, suurempi on parempi)

Lukija	Vertaisyhteys: aika	MB/s	tiedostoa/s	S3: aika	MB/s	tiedostoa/s	P2P vs. S3
Amsterdam, yksin	111 s (111 s / 111 s)	2.6	90.2	299 s (323 s / 274 s)	1.0	33.7	2.7× nopeampi
Varsova, yksin	260 s (258 s / 263 s)	1.1	38.4	294 s (269 s / 320 s)	1.0	34.2	1.1× nopeampi
Amsterdam, kaksi lukijaa	156 s (202 s / 110 s)	2.1	70.3	156 s (142 s / 170 s)	1.9	64.7	1.0× nopeampi
Varsova, kaksi lukijaa	259 s (265 s / 253 s)	1.1	38.6	192 s (161 s / 223 s)	1.6	53.5	1.3× hitaampi

Koontiversio	Lukija	Aika	MB/s	tiedostoa/s
S3 ennen tiedostojen yli ulottuvaa ennakkohakua (yksi tiedosto kerrallaan), 9. lokakuuta	Amsterdam, yksin	404 s (313 s / 495 s)	0.8	26.1
S3 ennen tiedostojen yli ulottuvaa ennakkohakua (yksi tiedosto kerrallaan), 9. lokakuuta	Amsterdam, kaksi lukijaa	381 s (381 s / 380 s)	0.8	26.2
S3 ennen tiedostojen yli ulottuvaa ennakkohakua (yksi tiedosto kerrallaan), 9. lokakuuta	Varsova, kaksi lukijaa	528 s (494 s / 563 s)	0.6	19.1
S3 ennen tiedostojen yli ulottuvaa ennakkohakua (yksi tiedosto kerrallaan), 9. lokakuuta	Varsova, yksin	596 s (536 s / 655 s)	0.5	16.9

Amsterdamiin vertaisyhteys toimitti 90 tiedostoa sekunnissa, 2.7 kertaa bucketin 34. Varsovaan, kolme ja puoli kertaa kauemmas, kumpikin pääsi samaan 34–38 tiedostoon sekunnissa: siellä pyyntökohtainen edestakainen viive hallitsee kummallakin reitillä. Tiedostojen yli ulottuva ennakkohaku kaksinkertaisti bucketin nopeuden Varsovaan (17:stä 34 tiedostoon sekunnissa) ja auttoi Amsterdamiin (26:sta 34:ään). Kun lohkot ovat perillä, kunkin tiedoston kirjoittaminen (data synkronoidaan levylle, uudelleennimeäminen, kirjanpidon tapahtumat) maksaa näillä verkkolohkotaltioilla muutaman millisekunnin, mikä rajaa minkä tahansa lähteen muutamaan sataan tiedostoon sekunnissa.

Kun molemmat lukijat latasivat yhtä aikaa, Varsova oli yhtä nopea kuin yksin, ja Amsterdamin kaksi ajoa erosivat toisistaan (202 s ja 110 s): lukijoiden lohkot haetaan siltä vertaiselta, joka vastaa ensin, ja toinen ajo odotti toista lukijaa enemmän kuin toinen. Bucket, joka mitattiin kahdella lukijalla kolme tuntia myöhemmin, toimitti Amsterdamiin 64 tiedostoa sekunnissa ja Varsovaan 53: lähes kaksi kertaa sen, mitä se antoi yksittäisille lukijoille aiemmassa istunnossa. Sen nopeus riippuu kellonajasta enemmän kuin lukijoiden määrästä.

Pakkautuva teksti

512 MiB lokirivejä, tallennettuna 138 MiB:nä. Tavuja kulkee vähemmän, joten lukija saa sekunnissa enemmän tiedostoa kuin satunnaisella datalla.

Vertaisyhteys (Pariisin kirjoittajalta) S3-bucket Pariisissa (MB/s, suurempi on parempi)

Lukija	Vertaisyhteys: aika	MB/s	S3: aika	MB/s	P2P vs. S3
Amsterdam, yksin	32 s (33 s / 31 s)	16.7	36 s (21 s / 52 s)	18.1	1.1× nopeampi
Varsova, yksin	74 s (70 s / 79 s)	7.2	32 s (32 s / 32 s)	16.7	2.3× hitaampi
Amsterdam, kaksi lukijaa	32 s (32 s / 31 s)	16.9	31 s (23 s / 39 s)	18.4	1.0× hitaampi
Varsova, kaksi lukijaa	66 s (63 s / 69 s)	8.1	63 s (28 s / 98 s)	12.3	1.0× hitaampi

Tässä bucket oli hieman nopeampi Amsterdamiin ja yli kaksi kertaa nopeampi Varsovaan. Kahdella lukijalla vertaisyhteys antoi Amsterdamille samat 16.9 MB/s kuin yksin ja Varsovalle 8.1 MB/s, hieman enemmän kuin yksin; kahdesta ajosta ensimmäisessä Varsova sai kaksi kolmasosaa lohkoistaan Amsterdamilta, toisessa kaikki Pariisista. Lohkon jakava laite ei säilytä pakattua kopiota: se lukee tavallisen tiedoston ja pakkaa lohkon uudelleen zstd-tasolla 12 jokaista pyyntöä varten; Pariisin laite käytti 31 s prosessoriaikaa jokaista jaettua 512 MiB:tä kohden, kun satunnaisen datan 4 GiB vei 40 s. Bucket palauttaa tallennetun objektin sellaisenaan.

Kirjoittajan puoli

Ennen kuin mitään voi ladata, kirjoittaja pilkkoo tiedostonsa lohkoiksi, pakkaa ja salaa ne ja tallentaa ne. Kolme kohdetta näyttää, mihin aika kuluu: RAM-levy (pelkkä Varston oma työ), koneen levy (verkkolohkotaltio, jolle jokainen objekti kirjoitetaan levysynkronoinnilla) ja bucket.

Aineisto	Kohde	Koontiversio	Aika	MB/s	Prosessoriaika (käyttäjä + järjestelmä)	Muistin huippukäyttö
tiedostot: 10 000 tiedostoa, 0.27 GiB	RAM-levy (tmpfs)	mitattu koontiversio	50 s (2 ajon mediaani)	5.9	12 s (5 + 7)	68 MiB
tiedostot: 10 000 tiedostoa, 0.27 GiB	S3-bucket, sama alue	mitattu koontiversio	652 s (2 ajon mediaani)	0.5	21 s (8 + 13)	69 MiB
pienet: 50 000 tiedostoa, 1.36 GiB	RAM-levy (tmpfs)	mitattu koontiversio	255 s (2 ajon mediaani)	5.7	62 s (27 + 35)	258 MiB
pienet: 50 000 tiedostoa, 1.36 GiB	Paikallinen levy (verkkolohkotaltio)	mitattu koontiversio	468 s	3.1	67 s (27 + 41)	258 MiB
pienet: 50 000 tiedostoa, 1.36 GiB	Paikallinen levy (verkkolohkotaltio)	alpha.8 (ennen zstd-korjausta)	515 s	2.8	109 s (31 + 78)	253 MiB
suuret: 2 tiedostoa, 4.00 GiB	S3-bucket, sama alue	mitattu koontiversio	932 s (2 ajon mediaani)	4.6	80 s (37 + 43)	108 MiB
isot: 5 tiedostoa, 12.00 GiB	Paikallinen levy (verkkolohkotaltio)	mitattu koontiversio	418 s	30.9	197 s (85 + 112)	147 MiB
isot: 5 tiedostoa, 12.00 GiB	Paikallinen levy (verkkolohkotaltio)	alpha.8 (ennen zstd-korjausta)	694 s	18.6	483 s (110 + 373)	137 MiB
teksti: 128 tiedostoa, 0.50 GiB	RAM-levy (tmpfs)	mitattu koontiversio	45 s (2 ajon mediaani)	12.0	44 s (41 + 2)	68 MiB
teksti: 128 tiedostoa, 0.50 GiB	Paikallinen levy (verkkolohkotaltio)	mitattu koontiversio	56 s	9.6	45 s (42 + 3)	68 MiB
teksti: 128 tiedostoa, 0.50 GiB	Paikallinen levy (verkkolohkotaltio)	alpha.8 (ennen zstd-korjausta)	68 s	7.9	56 s (43 + 13)	68 MiB
teksti: 128 tiedostoa, 0.50 GiB	S3-bucket, sama alue	mitattu koontiversio	145 s (2 ajon mediaani)	3.7	45 s (41 + 4)	77 MiB

• Satunnainen data maksaa zstd-korjauksen jälkeen näillä ytimillä noin 16 s prosessoriaikaa gibitavua kohden (12 GiB: 197 s), kun ennen korjausta kului 40 s gibitavua kohden.
• Teksti maksaa noin 85 s prosessoriaikaa gibitavua kohden: zstd tasolla 12, joka on formaatin vakio, on hidas pakkautuvalle datalle; sillä saadaan suhde 3.7 : 1, josta jokainen myöhempi siirto hyötyy.
• Pienet tiedostot eivät ole prosessorisidonnaisia edes RAM-levyllä: 10 000 tiedostoa vei 50 s, josta prosessoriaikaa 12 s. Laitteen looginen kello kirjoitetaan levylle kahdella synkronoinnilla jokaista lähetettyä tiedostoa kohden. Tätä ei ole vielä korjattu.
• Bucket on ylivoimaisesti hitain: jokainen lohko on HEAD ja PUT peräkkäin. 10 000 tiedostoa vei 622 s ja 681 s, 4 GiB 578 s ja 1 287 s kahtena päivänä. Lähetykset eivät ole vielä rinnakkaisia.

Matkan varrella korjattua

Mittaus oli myös pullonkaulojen metsästystä. Nämä muutokset ovat mukana mitatuissa koontiversioissa, ja kullekin on testi:

Ongelma	Korjaus	Ennen	Jälkeen
Lataus haki yhden lohkon kerrallaan: jokainen lohko odotti kokonaisen edestakaisen viiveen ennen kuin seuraavaa pyydettiin.	Enintään kahdeksan tiedoston lohkoa matkalla yhtä aikaa vertaisilta tai tallennuspaikoista liukuvassa ikkunassa; ne tarkistetaan ja kirjoitetaan yhä järjestyksessä. S3-asiakas pitää riittävästi vapaita yhteyksiä niitä varten.	Teksti bucketista Varsovaan: 122 s (4.4 MB/s)	27.8 s (19.4 MB/s), 4.4 kertaa nopeampi (yksittäiset ajot; välivaiheet: kahdeksan lohkon kiinteät erät 104 s, vapaat yhteydet säilyttäen 61 s)
Pienet tiedostot kulkivat yksi kerrallaan: kukin tiedosto on yksi lohko, joten yllä oleva ikkuna ei koskaan vaikuttanut.	Nouto hakee enintään 32 tulevan yhden lohkon tiedoston lohkot yhdessä (10.10.).	10 000 tiedostoa bucketista Varsovaan: 596 s (17 tiedostoa/s)	294 s (34 tiedostoa/s)
Vertaisyhteyden HTTP-palvelin vastasi yhteen pyyntöön kerrallaan, joten kahdeksan matkalla olevaa pyyntöä jonottivat palvelimella.	Kahdeksaan pyyntöön vastataan yhtä aikaa.	Suuret tiedostot vertaisyhteydellä Amsterdamiin: 363 s (11.8 MB/s), yksi ajo	159 s (27.0 MB/s)
Jokaista lohkoa varten luotiin uusi zstd-konteksti; sen taulukot varattiin ja tyhjennettiin joka kerta, mikä oli enemmän työtä kuin lohkon pakkaaminen.	Yksi konteksti säiettä kohden, uudelleenkäytettynä (tuloste on tavu tavulta sama, minkä testi tarkistaa).	12 GiB paikalliselle levylle: 694 s, 483 s prosessoriaikaa	418 s, 197 s prosessoriaikaa (yksittäiset ajot)
S3-asiakas hylkäsi kaikki yli 10 MiB:n vastaukset. Muutaman tuhannen tiedoston lähetyksen jälkeen kirjanpidon erä oli 13 MB, eikä mikään muu laite voinut liittyä tai synkronoida.	Enintään 2 GiB:n vastaukset luetaan.	Liittyminen epäonnistui	Liittyminen toimii; testi 12 MiB:n objektilla
Taustapalvelu piti jokaista avattua tiedostoa muutoksena: lohkojen jakaminen vertaisille, varmuuskopiointityökalu tai tiedostojen katseluohjelma käynnisti täyden synkronoinnin muutaman sekunnin välein.	Avaaminen ja lukeminen eivät ole muutoksia; kirjoittamista varten avatun tiedoston sulkeminen on yhä muutos.	90 synkronointia 11 minuutissa tiedostoja luettaessa	Kaikkien 10 000 tiedoston lukeminen: ei ylimääräistä synkronointia
Yhtä aikaa matkalla olevat pyynnöt avasivat kukin oman QUIC-yhteytensä vertaiseen, johon ei vielä ollut yhteyttä.	Yksi yhteysyritys osoitetta kohden; muut odottavat ja käyttävät sitä yhdessä (testi tarkistaa, että koko noudolle riittää yksi yhteys).	Löytyi QUICia testattaessa (alla)
Säilytetty QUIC-yhteys uudelleenkäynnistyneeseen vertaiseen epäonnistui jokaisella pyynnöllä, ja vertainen putosi pysyvästi seuraavalle reitille.	Yhdistetään kerran uudelleen ja kysytään uudestaan.	Löytyi QUICia testattaessa (alla)
Vanhalla reitillä valmistuneet pyynnöt saattoivat kumota vaihdon parempaan reittiin, jonka toinen pyyntö oli juuri tehnyt.	Myöhään tullut vastaus säilyttää nykyisen reitin.	Löytyi QUICia testattaessa (alla)

Kokeiltu ja peruttu: QUIC ensin

Koska TCP-reitti avaa yhteyden jokaista lohkoa kohden, QUIC vaikutti ratkaisulta: Varsto käyttää jo QUICia NATin takana oleviin vertaisiin, yksi yhteys vertaista kohden ja yksi virta pyyntöä kohden. Lokakuun 10. päivänä reittijärjestys muutettiin niin, että lähiverkon ulkopuolisille osoitteille kokeillaan QUICia ennen TCP:tä. Näillä koneilla se oli hitaampi ja käytti yli kaksi kertaa enemmän prosessoriaikaa:

Suuret tiedostot, vertaisyhteys	TCP ensin (säilytetty)	QUIC ensin (peruttu)
Amsterdam	159 s, 27.0 MB/s; lukija 38 s prosessoriaikaa, Pariisi 40 s	230 s, 18.7 MB/s (229 s / 230 s); lukija 98 s prosessoriaikaa, Pariisi 88 s
Varsova	423 s, 10.2 MB/s	466 s, 9.2 MB/s (yksi ajo); lukija 130 s prosessoriaikaa

TCP pysyy siis ensimmäisenä, ja QUIC on edelleen tie NATien läpi. Sitä, mihin QUIC-reitti aikansa menettää, ei käytettävissä olleessa ajassa löydetty; isäntäkone ei pudottanut yhtään UDP-pakettia. Kokeilu toi esiin myös puutteen, jota ei ole vielä korjattu: laitteen vertaistaulukko rakennetaan ennen kuin synkronointi lukee laiterekisterin, joten juuri liittynyt laite saa vertaisiltaan kieltävän vastauksen QUICin kautta niiden seuraavaan synkronointiin asti (TCP:n kautta sitä palvellaan heti).

Yhä hidasta, ja miksi

• Yksi TCP-yhteys lohkoa kohden vertaisreitillä (tässä mitatut koontiversiot). Jokainen pyyntö maksoi kättelyn ja uuden hitaan aloituksen, ja juuri se rajoitti Varsovaa. Muutettu sittemmin: yhteydet vertaiseen pidetään nyt auki pyyntöjen välillä, matkalla voi olla enintään 32 pyyntöä, ikkuna seuraa mitattua läpäisyä, eikä pakkaamattomina tallennettuja lohkoja enää pakata uudelleen jaettaessa. Yhdellä koneella, jossa verkkonimiavaruus jäljitteli 32 ms:n edestakaista viivettä (Pariisi–Varsova) 800 Mbit/s:n nopeudella ja joka kuljetti 62 MB/s yhdessä TCP-virrassa ja 81 MB/s kuudessatoista, vertaisyhteys nopeutui pakkautumattomalla datalla 10.4:stä 44.7 MB/s:iin ja tekstillä 11.3:sta 38.6 MB/s:iin, ja bucket (jota palveli rclone serve s3 saman yhteyden yli) 41.5:stä 45.5:een ja 39.1:stä 52.8 MB/s:iin (kahden ajon keskiarvot). Nämä ovat paikallisia mittauksia eivätkä yllä olevien ajojen toistoja; mittausohjelma on scripts/bench/netem-local.sh.
• Pakkautuvan datan jakaminen kuluttaa prosessoriaikaa, koska jokainen pyyntö pakkaa lohkon uudelleen; siksi teksti vertaisyhteydellä jää jäljittelyssä bucketin alle. Yhdelle vertaiselle pakatut lohkot pidetään nyt muistissa (oletuksena 64 MiB) seuraavaa pyytävää laitetta varten, esimerkiksi kun useampi laite kirii samaan aikaan ajan tasalle.
• Lataus, jossa vertaisyhteys on päällä, käyttää nyt myös bucketia, kun se vastaa nopeammin, nopeutensa suhteessa. Jäljittelyssä molemmat jakoivat yhden yhteyden, joten molempien käyttö ei ollut nopeampaa kuin kumpikaan yksin (44.4 MB/s molemmilla aineistoilla); todellisissa verkoissa reitit eroavat toisistaan.
• Monen pienen tiedoston kirjoittaminen maksaa lukijalla yhden levysynkronoinnin tiedostoa kohden ja kirjoittajalla kaksi synkronointia tiedostoa kohden loogisen kellon vuoksi.
• Lähetykset bucketiin kulkevat lohko kerrallaan, ja jokaista PUT-pyyntöä edeltää HEAD.
• Kirjanpito kasvaa noin 1 KB lohkoa kohden: 4 GiB:n aineiston lähettäminen kirjoitti 13 MB:n kirjanpitoerän, jonka jokainen laite lukee liittyessään.

Milloin vertaisyhteys voittaa ja milloin bucket

Varsto käyttää tarkoituksella molempia, ja mittaukset näyttävät miksi.

• Vertaisyhteys tarvitsee vertaisen verkkoon. Lukijat pystyivät hakemaan tiedot vain, koska lohkot omistava laite oli käynnissä. Bucket on aina paikalla: suljettu kannettava, laatikossa oleva puhelin ja laitteet, jotka eivät koskaan ole verkossa yhtä aikaa, synkronoituvat kaikki silti sen kautta. Siksi holvissa on aina vähintään yksi tallennuspaikka, ja siksi tiedostoluettelot ja kirjanpito pysyvät siinä.
• Lähellä olevien laitteiden välillä vertaisyhteys voittaa: paljon pieniä tiedostoja Amsterdamiin 2.7 kertaa nopeammin kuin bucketista samassa istunnossa (myöhemmässä istunnossa bucket pääsi lähelle) ja suuret tiedostot hieman nopeammin ja paljon tasaisemmin. Lähiverkossa edestakainen viive on millisekunnin murto-osa.
• Laitteet, joilla data jo on, jakavat sitä. Kahdella lukijalla Varsova sai suurimman osan lohkoistaan Amsterdamilta; ensimmäisenä synkronoiva laite muuttuu lähteeksi seuraavalle, ja kirjoittajan lähetyskaista säästyy.
• Kaukana olevilla laitteilla ja pakkautuvalla datalla bucket voitti näillä yhteyksillä: suuret tiedostot ja teksti Varsovaan sekä niukasti teksti Amsterdamiin. Syyt tunnetaan (yhteys lohkoa kohden, uudelleenpakkaus jaettaessa), eivätkä ne ole verkossa: yhteys Varsovaan kuljetti 777 Mbit/s yhdessä virrassa.
• Bucket skaalautuu monille lukijoille kuluttamatta kenenkään lähetyskaistaa; monia muita palveleva kotilaite on lähetysnopeutensa rajoittama, elleivät lukijat auta toisiaan kuten edellä.
• Vertaisyhteys ei maksa mitään gigatavua kohden eikä jätä kopiota palveluntarjoajalle. Data kulkee laitteeltasi laitteellesi; bucket tarvitsee lohkot vain niitä laitteita varten, jotka ovat poissa verkosta silloin, kun muut niitä haluavat.

Kustannukset

Scalewayn julkinen hinnasto (luettu 9. lokakuuta 2026, Pariisin alue, verottomat hinnat): Object Storage Standard Multi-AZ €0.000022 gigatavutunnilta (noin €0.016 gigatavukuukaudelta), pyynnöt sisältyvät, sisääntuleva liikenne sisältyy, ulosmenevästä liikenteestä ensimmäiset 75 GB kuukaudessa ilmaisia ja sen jälkeen €0.01 gigatavulta. Alueiden väliset siirrot (Pariisi – Amsterdam, Pariisi – Varsova) lasketaan ulosmeneväksi liikenteeksi; alueen sisällä ne ovat ilmaisia.

Yksi Amsterdamin lukija, joka lataa 4 GiB:n aineiston Pariisin bucketista, maksaa siis noin €0.04, kun ilmaiset 75 GB on käytetty, ja kotitalous, joka synkronoi 500 GB kuukaudessa bucketin alueen ulkopuolisille laitteille, maksaa ulosmenevästä liikenteestä noin €4 kuukaudessa. Vertaisyhteys siirtää samat tavut laitteiden omien yhteyksien kautta eikä lisää tallennuslaskuun mitään. Muut palveluntarjoajat veloittavat ulosmenevästä liikenteestä tai pyynnöistä enemmän; yllä kuvattu menetelmä soveltuu niihin sellaisenaan. Tämän mittauksen koneet (kolme instanssia hintaan €0.147 tunnilta, noin seitsemän ja puoli tuntia kahtena päivänä) maksoivat noin €3.50.

Mittauksen rajoitukset

• Kaksi päivää, kaksi koontiversiota. Suurten tiedostojen ajot yksittäisillä lukijoilla ja osa bucket-ajoista ovat 9. lokakuuta, loput 10. lokakuuta; niiden väliset muutokset eivät koske vertailtuja tapauksia (katso yllä). Bucketin nopeus erosi päivien välillä.
• Pilvikoneita, ei koteja. Datakeskusyhteydet, julkiset osoitteet verkkoliitännässä, ei NATia, ei Wi-Fiä. Kotona vertaisyhteys internetin yli kulkee yleensä QUICilla reiänlyönnillä avatun NATin läpi, ja näissä ajoissa sitä mitattiin vain perutussa kokeilussa; kodin lähetysnopeus olisi usein rajoittava tekijä.
• Saman palveluntarjoajan kolme aluetta Euroopassa. Bucket ja koneet jakavat palveluntarjoajan ja sen runkoverkon; muilla palveluntarjoajilla ja pidemmillä etäisyyksillä tulokset ovat erilaisia.
• Verkkolohkotaltiot tekevät jokaisesta levysynkronoinnista hitaan (millisekunteja), mikä painaa pienten tiedostojen kohdalla; kannettavan SSD-levy synkronoi nopeammin.
• Kaksi ajoa tapausta kohden on vähän; bucketin tulokset vaihtelivat toistojen välillä jopa 58 % pienillä tiedostoilla ja 3.5-kertaisesti tekstillä, ja bucketin nopeus pienillä tiedostoilla lähes kaksinkertaistui saman päivän kahden istunnon välillä.
• Alfavaiheen ohjelmisto. Formaatit ja oletusarvot voivat vielä muuttua, ja niin muuttuvat myös nämä luvut.

Toistaminen: scripts/bench/p2p-bench.py luo koneet ja bucketin Scalewayn komentorivityökalulla, ajaa jokaisen vaiheen, kirjoittaa tiedoston results.jsonl ja poistaa lopuksi kaiken; report.py ja page.py muuttavat tulokset tämän sivun yhteenvedoksi ja taulukoiksi.