Prestandamätningar: peer-to-peer tvärs över Europa

En enhet i Paris har filerna. Enheter i Amsterdam och Warszawa ansluter till valvet med en tom mapp och laddar ned allt: en gång direkt från enheten i Paris och från varandra (peer-to-peer), en gång från en S3-bucket i Paris. Uppmätt den 9 och 10 oktober 2026 på hyrda molnmaskiner.

Den här sidan redovisar vad som mättes, hur, vad som begränsade det och vad som ändrades i Varsto till följd av det. Alla planerade fall har nu siffror, från två körningar vardera om inte en tabell säger annat. Siffrorna gäller en alfaversion: de beskriver koden som den såg ut de dagarna. Sedan 0.0.1-alpha.11 delas stora filer upp i större block (i genomsnitt 1 MiB från 32 MiB, 4 MiB från 1 GiB), så blockantalen här gäller inte längre för dem. Mätskriptet finns i repositoryt under scripts/bench/, och de sammanfattade resultaten publiceras som JSON, så att varje siffra på sidan kan kontrolleras och körningen upprepas.

Sammanfattning

• Från en hemanslutning bakom NAT (100 Mbit/s): var och en av 14 överföringar mellan en hemdator och servrar i Amsterdam och Warszawa kom enbart från andra enheter: genom hemrouterns NAT, från NAT till NAT och genom en symmetrisk NAT via relä. Stora filer gick i 8.0 till 9.3 MB/s, 1.3 till 1.8 gånger så snabbt som samma nedladdning från bucketen på samma linje. Detaljer.
• Många små filer, Paris till Amsterdam (9 ms ifrån varandra): 10 000 filer kom fram peer-to-peer på 111 s (90 filer/s) och från bucketen på 299 s (34 filer/s): peer-to-peer var 2.7 gånger snabbare. Till Warszawa (33 ms bort) låg de nära varandra: 260 s mot 294 s. Bucketens hastighet varierade dock med tiden på dygnet: tre timmar senare, med två läsare samtidigt, levererade den 64 filer/s till Amsterdam och 53 till Warszawa, nära peer-to-peers 70 och 39 med två läsare.
• Stora filer: till Amsterdam 4 GiB peer-to-peer på 159 s (27.0 MB/s) mot 180 s (23.9 MB/s) från bucketen, och betydligt jämnare. Till Warszawa var bucketen snabbare: 190 s (23.4 MB/s) mot 423 s (10.2 MB/s). Peer-to-peer-vägen öppnar en TCP-anslutning för varje block, vilket kostar rundresor; ju längre avstånd, desto mer.
• Två läsare samtidigt, peer-to-peer: läsarna hjälper varandra. Warszawa hämtade 69 % av sina block från Amsterdam, som redan hade dem, och bara 31 % från Paris, så enheten i Paris skickade 5.6 GB i stället för 8.6 GB. Ingen av läsarna blev långsammare.
• Komprimerbar text: bucketen var lite snabbare till Amsterdam (18.1 mot 16.7 MB/s) och mer än dubbelt så snabb till Warszawa (16.7 mot 7.3 MB/s). En enhet som levererar text komprimerar varje block på nytt för varje begäran, på en nivå vald för liten lagring, inte för hastighet.
• Varje block i peer-to-peer-körningarna kom från en annan enhet: 202 544 av 202 544 block i 24 uppmätta nedladdningar, inget från bucketen, vars block hade raderats; varje fil stämde med sin SHA-256 efteråt.
• Körningarna hittade och åtgärdade nio problem, bland dem nedladdningar som hämtade ett block i taget (nu åtta samtidigt, och små filer hämtas i förväg över filgränserna) och en peer-to-peer-server som besvarade en begäran i taget. Att göra QUIC till föredragen väg över internet provades, mättes som långsammare här och återställdes. Detaljer och siffror.

Från ett hem bakom NAT (10 oktober)

Körningarna ovan är mellan datacenter med publika adresser. Dessa är från ett hem: en stationär dator på en konsumentanslutning på 100 Mbit/s bakom routerns NAT, med Varsto installerat så som en användare installerar det (Linux-paketet, en bakgrundstjänst för användaren). Två molnmaskiner anslöt till den: en i Amsterdam med publik adress, och en i Warszawa med två enheter i nätverksnamnrymder bakom NAT, en bakom en kon-NAT (Linux MASQUERADE behåller porten) och en bakom en symmetrisk NAT (MASQUERADE med slumpmässiga portar, vilket omintetgör hålslagning). Liksom ovan innehöll bucketen i Paris bara liggaren och fillistorna: före varje hämtning raderades dess block, så att varje block måste komma från en annan enhet, och varje fil kontrollerades mot sin SHA-256. Mätskriptet är scripts/nat-test/home-nat.py.

Linjen

Hemdatorn och	Rundresa	TCP, en ström, till hemmet	TCP, en ström, från hemmet
Amsterdam	31 ms	9.1 MB/s	12.1 MB/s
Warszawa	21 ms	10.6 MB/s	11.9 MB/s
Bucketen (Paris), rclone, 256 MiB	–	7.5 MB/s	4.3 MB/s

100 Mbit/s är högst 12.5 MB/s, så det är taket för allt på den här linjen.

Genom NAT

STUN klassade hemroutern som en kon-NAT. Varje överföring flyttade en fil på 64 MiB med slumpmässiga byte; vid den storleken utgör den fasta kostnaden för en synkronisering (liggare och fillista i bucketen) en stor del av tiden.

Från	Till	Väg som mottagaren använde	Tid	Hastighet
Hemmet	Amsterdam (publik)	direkt, in genom hemmets NAT	12.2 s	5.5 MB/s
Amsterdam	Hemmet	direkt	14.3 s	4.7 MB/s
Warszawa, kon-NAT	Hemmet	direkt, NAT till NAT (hålslagning)	13.3 s	5.0 MB/s
Hemmet	Warszawa, kon-NAT	direkt, NAT till NAT	14.5 s	4.6 MB/s
Warszawa, symmetrisk NAT	Hemmet	via relä i Amsterdam	65.7 s	1.0 MB/s
Hemmet	Warszawa, symmetrisk NAT	via relä i Amsterdam	65.3 s	1.0 MB/s

Varje väg fungerade så som designen säger: direkt där en NAT behåller sin mappning, via ett relä genom en av användarens egna nåbara enheter där den inte gör det. Ingen leverantörsserver var inblandad; enheterna hittade varandra genom poster i bucketen och publika STUN-servrar.

Stora filer

En fil på 512 MiB med slumpmässiga byte per överföring, enbart peer-to-peer. Första kolumnen är version 0.0.1-alpha.9 med reläåtgärden nedan; den andra lägger till samma dags ändringar i nedladdningen (anslutningar hålls öppna per enhet, objekt skickas utan att komprimeras på nytt, ett fönster som anpassar sig mellan 8 och 32 block).

Överföring	Före ändringarna	Med ändringarna	Andel av en TCP-ström	Andel av 100 Mbit/s
Amsterdam → hemmet	4.7 MB/s	8.0 MB/s	88 %	64 %
Warszawa (kon-NAT) → hemmet	6.9 MB/s	9.3 MB/s	88 %	74 %
Hemmet → Amsterdam	8.7 MB/s	9.3 MB/s	77 %	74 %
Hemmet → Warszawa (kon-NAT)	–	8.6 MB/s	72 %	69 %

Samma nedladdning från bucketen

En andra enhet på hemdatorn, med peer-to-peer avstängt, hämtade en fil på 512 MiB som en server just hade laddat upp till bucketen, över samma linje.

Skriven av	Från bucketen	Peer-to-peer (ovan)	Peer-to-peer var
Amsterdam	6.1 MB/s	8.0 MB/s	1.3 gånger så snabb
Warszawa (kon-NAT)	5.2 MB/s	9.3 MB/s	1.8 gånger så snabb

Mellan datacenter hänger bucketen med, eftersom bucketen och maskinerna sitter på samma snabba stamnät. Från ett hem är bucketen ytterligare ett avlägset steg med sin egen kostnad per begäran, medan en annan enhet skickar rakt ned i linjen.

Hittat och åtgärdat

• Reläet kunde inte nå enheten det reläar för. En enhet bakom en symmetrisk NAT håller en anslutning öppen till en nåbar enhet i valvet, och andra enheter når den genom det reläet. Själva reläet hade ingen väg till den: det reläade inte genom sig självt och fortsatte ringa upp adresser som ingen kan nå. Nu frågar det en sådan enhet över den anslutning som enheten håller öppen till det.
• Peer-to-peer-nedladdningar nära linjens hastighet. Ändringarna ovan ungefär fördubblade nedladdningen från Amsterdam till hemmet (4.7 till 8.0 MB/s).

Fortfarande långsamt

• Vägen via relä klarade bara 1 till 1.6 MB/s: varje block färdas som en egen begäran över två steg, hemmet till Amsterdam till Warszawa och tillbaka. Det är reservvägen för de svåraste NAT-typerna, men den borde ändå fylla mer av linjen.
• Små överföringar betalar en fast kostnad för liggaren och fillistan i bucketen: 64 MiB tog 12 till 15 s där enbart byten behöver ungefär 7.
• Tjänstens gränssnitt kunde vänta i minuter på svar medan en synkronisering pågick och fortsatte försöka nå en enhet som inte gick att nå; statusanropen borde inte vänta på synkroniseringen.

Begränsningar: en hemanslutning, en eftermiddag, en körning per fall (en upprepning av Warszawa till hemmet under skärmbilden gick i 5.2 MB/s, med Amsterdam tillfälligt onåbart); NAT i Warszawa är Linux egen, inte en konsumentrouters; servrarna var små (Scaleway DEV1-M). Ändringarna i nedladdningen granskas och är ännu inte släppta.

Vad som mättes

Datamängd	Från bucketen (S3)	Peer-to-peer
Stora filer (2 × 2 GiB)	Amsterdam, Warszawa, båda samtidigt (9 okt)	Amsterdam, Warszawa (9 okt); båda samtidigt (10 okt)
Många små filer (10 000)	Amsterdam, Warszawa, båda samtidigt (10 okt; körningarna från 9 okt behålls som ”före förhandshämtning”)	Amsterdam, Warszawa, båda samtidigt (10 okt)
Komprimerbar text (512 MiB)	Amsterdam, Warszawa (9 okt); båda samtidigt (10 okt)	Amsterdam, Warszawa, båda samtidigt (10 okt)
Skrivarens uppladdning	2 körningar per mängd, en varje dag	RAM-disk: 2 körningar per mängd; lokal disk: 1 körning per mängd

Två körningar per fall; tiderna i tabellerna är deras median (medelvärdet av två), med båda körningarna bredvid. Enskilda körningar anges som sådana. Mellan de två dagarna ändrades nedladdningskoden bara på sätt som inte berör de jämförda fallen: körningarna med stora filer och text den 9 oktober hämtar block inom en fil exakt som versionen från den 10 oktober gör, och bucketkörningarna med många små filer upprepades den 10 oktober eftersom förhandshämtning över filgränserna är ny. De två sista fallen, komprimerbar text peer-to-peer och många små filer från bucketen, båda med två läsare samtidigt, kördes tre timmar efter de andra på nya maskiner med den sammanslagna versionen; bucketen var tydligt snabbare under den sessionen än under den tidigare.

Uppställning och referensvärden

• Maskiner: tre Scaleway POP2-4C-16G-instanser (4 vCPU AMD EPYC 7543, 16 GB RAM, 80 GB nätverksblockvolym, Ubuntu 24.04), nyskapade varje dag: skrivaren i Paris (fr-par-1), läsare i Amsterdam (nl-ams-1) och Warszawa (pl-waw-1). Varje maskin hade en publik IPv4-adress på sitt eget gränssnitt, så det fanns ingen NAT mellan dem.
• Bucket: en tillfällig bucket i Scaleway Object Storage i Paris (fr-par), skrivarens region. Läsarna i Amsterdam och Warszawa läste den över landsgränser.
• Varsto: 0.0.1-alpha.8 med åtgärderna nedan, en statisk Linux-version (musl). 9 oktober: commits till och med 37bee19 (bucketkörningar: 0180ca8, som bara skiljer sig i peer-to-peer-servern och filbevakaren). 10 oktober: commit 9b93263 för peer-to-peer-körningarna; dagens tidigare bucketkörningar använde a3ba1c0, som bara skiljer sig i ordningen mellan peer-to-peer-vägarna; de två fall som kördes sist använde den sammanslagna versionen dc09721, samma kod som 9b93263 för dessa körningar.
• En körning: en ny enhet ansluter till valvet med valvnyckeln, startar bakgrundstjänsten, pausar den, kopplar in en tom mapp och ber tjänsten om en synkronisering av den mappen (POST /api/sync). Tiden räknas från den begäran till svaret: fillistan läses, varje block hämtas, kontrolleras mot sin hash, dekrypteras, kontrolleras mot chunk-id:t och skrivs. Efteråt jämför mätskriptet en SHA-256-lista över mappen med skrivarens. Sedan tas enheten bort igen. Automatisk verifiering var avstängd på alla mätenheter, eftersom den laddar ned och reparerar block i bakgrunden.

Nätverkets referensvärden

Mellan	Rundresa (ping)	TCP, en ström (iperf3, Paris skickar), 9 / 10 okt	TCP, fyra strömmar
Paris – Amsterdam	9.4 ms	925 / 958 Mbit/s	875 / 836 Mbit/s
Paris – Warszawa	33.4 ms	738 / 777 Mbit/s	949 / 909 Mbit/s
Amsterdam – Warszawa	20.6 ms	–	–

Läsare	S3: ett objekt på 256 MiB, en ström (rclone), 9 / 10 okt	S3: objekt på 4 KiB efter varandra, 9 / 10 okt
Paris	91 / 59 MB/s	7 / 45 ms styck
Amsterdam	26 / 21 MB/s	16 / 107 ms styck
Warszawa	52 / 15 MB/s	52 / 122 ms styck

Förbindelserna mellan maskinerna klarade 700 till 950 Mbit/s (90 till 120 MB/s) i en TCP-ström, och ingen av Varstos överföringar kom i närheten: alla begränsades av rundresor och arbete per begäran. Bucketens egen hastighet varierade mycket från en dag till nästa (den andra mätningen gjordes tidigt på morgonen); dess körningar varierade genomgående mer än peer-to-peer-körningarna.

Datamängder

• Stora filer: två filer på 2 GiB med slumpmässiga (okomprimerbara) byte, 4 GiB totalt, omkring 13 400 block.
• Många små filer: 10 000 filer i 500 kataloger, storlekar dragna ur en log-normalfördelning med median 16 KiB, begränsade till 1 KiB…256 KiB, var tjugonde fil en kopia av en annan; 281 MiB totalt. En mängd på 50 000 filer med samma form laddades upp, men inte ned.
• Komprimerbar text: 128 filer på 4 MiB med genererade loggrader från en webbserver, 512 MiB totalt; zstd lagrar dem på 138 MiB.

Vad ”bara peer-to-peer” betyder

Varsto frågar andra enheter först och lagringsplatser i andra hand, så en peer-to-peer-mätning måste se till att bucketen inte kan hjälpa till. När skrivaren hade laddat upp och bucketkörningarna var klara raderades varje objekt under chunks/ från bucketen. Bucketen behöll det som enheterna behöver för att hitta varandra och veta vad som finns (signerad liggare, fillistor, enhets- och peer-poster), men inget filinnehåll: ett block som ingen enhet kunde leverera skulle ha gjort filen otillgänglig. Sedan:

• varje körnings hämtningsrapport räknade block från andra enheter och block totalt, och mätskriptet underkände varje körning där de två skilde sig;
• läsarnas trafikräknare (/api/p2p/traffic) och skrivarens stämde överens: med en läsare tog läsaren emot exakt datamängdens lagrade storlek från writer-paris och skrivaren skickade lika mycket; med två läsare blev det som var och en tog emot från Paris och från den andra läsaren tillsammans den lagrade storleken, och enheten i Paris skickade resten;
• vägen var direkt i varje körning, över TCP till skrivarens publika adress på port 17893 (tjänstens logg anger vilken väg den valde), och mellan de två läsarna i körningarna med båda samtidigt. Inget relä var inblandat; en LAN-väg var omöjlig mellan tre länder.

Körning	Nedladdade chunks	Från andra enheter	Från S3	Väg
filer, Amsterdam, ensam (×2)	20 240	20 240	0	writer-paris: direkt
filer, Amsterdam, båda samtidigt (×2)	20 240	20 240	0	waw-p2p-files-ams+waw-1: direkt, writer-paris: direkt
filer, Warszawa, båda samtidigt (×2)	20 240	20 240	0	: direkt, ams-p2p-files-ams+waw-2: , writer-paris: direkt
filer, Warszawa, ensam (×2)	20 240	20 240	0	writer-paris: direkt
stora, Amsterdam, ensam (×2)	26 946	26 946	0	writer-paris: direkt
stora, Amsterdam, båda samtidigt (×2)	26 758	26 758	0	: direkt, writer-paris: direkt
stora, Warszawa, båda samtidigt (×2)	26 758	26 758	0	ams-p2p-large-ams+waw-1: direkt, ams-p2p-large-ams+waw-2: direkt, writer-paris: direkt
stora, Warszawa, ensam (×2)	26 946	26 946	0	writer-paris: direkt
text, Amsterdam, ensam (×2)	3 544	3 544	0	writer-paris: direkt
text, Amsterdam, båda samtidigt (×2)	3 544	3 544	0	: direkt, writer-paris: direkt
text, Warszawa, båda samtidigt (×2)	3 544	3 544	0	ams-p2p-text-ams+waw-1: direkt, writer-paris: direkt
text, Warszawa, ensam (×2)	3 544	3 544	0	writer-paris: direkt

Stora filer

4 GiB i två filer, slumpmässigt innehåll, så zstd lagrar det som det är.

Peer-to-peer (från skrivaren i Paris) S3-bucket i Paris (MB/s, mer är bättre)

Läsare	Peer-to-peer: tid	MB/s	S3: tid	MB/s	P2P mot S3
Amsterdam, ensam	159 s (158 s / 161 s)	27.0	180 s (171 s / 190 s)	23.9	1.1× snabbare
Warszawa, ensam	423 s (420 s / 426 s)	10.2	190 s (155 s / 226 s)	23.4	2.2× långsammare
Amsterdam, båda samtidigt	162 s (162 s / 161 s)	26.6	95 s (90 s / 101 s)	45.2	1.7× långsammare
Warszawa, båda samtidigt	365 s (367 s / 362 s)	11.8	208 s (185 s / 232 s)	20.9	1.8× långsammare

Version	Läsare	Tid	MB/s
Peer-to-peer med QUIC provat före TCP (en anslutning per enhet), 10 oktober	Amsterdam, ensam	230 s (229 s / 230 s)	18.7
Peer-to-peer med QUIC provat före TCP (en anslutning per enhet), 10 oktober	Warszawa, ensam	466 s (466 s)	9.2

Till Amsterdam, nio millisekunder bort, slog peer-to-peer bucketen med liten marginal och var betydligt jämnare: varje peer-to-peer-körning tog 158 s till 162 s, bucketens 171 s och 190 s. Till Warszawa var bucketen mer än dubbelt så snabb. Varje block på omkring 300 KiB är en HTTP-begäran på en ny TCP-anslutning: en handskakning, sedan TCP slow start från tio paket, så ett block behöver flera rundresor hur snabb förbindelsen än är. Vid 33 ms begränsar det åtta samtidiga begäranden till ungefär 10 MB/s, vilket är just vad som uppmättes. Bucketens HTTPS-anslutningar hålls öppna mellan begärandena.

Med båda läsarna samtidigt hämtade Warszawa 2.97 GB av sina 4.30 GB från Amsterdam (20 ms bort, närmare än Paris) och bara 1.3 GB från Paris; Amsterdam, som hade blocken först, levererade dem medan det laddade ned. Warszawa var till och med lite snabbare än ensamt (11.8 mot 10.2 MB/s) och Amsterdam lika snabbt som ensamt. Bucketen betjänade också två läsare samtidigt utan att någon av dem blev långsammare (45 och 21 MB/s); den är delad infrastruktur byggd för många läsare.

Läsarens eget arbete: omkring 40 s CPU-tid för 4 GiB (dekryptering, två hashar per block, skrivning), högst 490 MB minne. Enheten i Paris använde 40 s CPU-tid för att leverera varje 4 GiB, en kärna ungefär till en fjärdedel upptagen.

Många små filer

10 000 filer på 1 KiB till 256 KiB. Varje fil är ett block. Sedan den 10 oktober hämtar en hämtning blocken för upp till 32 kommande filer tillsammans, åtta begäranden åt gången, innan de skrivs en och en.

Peer-to-peer (från skrivaren i Paris) S3-bucket i Paris (filer/s, mer är bättre)

Läsare	Peer-to-peer: tid	MB/s	filer/s	S3: tid	MB/s	filer/s	P2P mot S3
Amsterdam, ensam	111 s (111 s / 111 s)	2.6	90.2	299 s (323 s / 274 s)	1.0	33.7	2.7× snabbare
Warszawa, ensam	260 s (258 s / 263 s)	1.1	38.4	294 s (269 s / 320 s)	1.0	34.2	1.1× snabbare
Amsterdam, båda samtidigt	156 s (202 s / 110 s)	2.1	70.3	156 s (142 s / 170 s)	1.9	64.7	1.0× snabbare
Warszawa, båda samtidigt	259 s (265 s / 253 s)	1.1	38.6	192 s (161 s / 223 s)	1.6	53.5	1.3× långsammare

Version	Läsare	Tid	MB/s	filer/s
S3 före förhandshämtning över filgränserna (en fil i taget), 9 oktober	Amsterdam, ensam	404 s (313 s / 495 s)	0.8	26.1
S3 före förhandshämtning över filgränserna (en fil i taget), 9 oktober	Amsterdam, båda samtidigt	381 s (381 s / 380 s)	0.8	26.2
S3 före förhandshämtning över filgränserna (en fil i taget), 9 oktober	Warszawa, båda samtidigt	528 s (494 s / 563 s)	0.6	19.1
S3 före förhandshämtning över filgränserna (en fil i taget), 9 oktober	Warszawa, ensam	596 s (536 s / 655 s)	0.5	16.9

Till Amsterdam levererade peer-to-peer 90 filer i sekunden, 2.7 gånger bucketens 34. Till Warszawa, tre och en halv gånger längre bort, kom båda upp i samma 34 till 38 filer i sekunden: där dominerar rundresan per begäran, på båda vägarna. Förhandshämtning över filgränserna fördubblade bucketens hastighet till Warszawa (från 17 till 34 filer i sekunden) och hjälpte till Amsterdam (26 till 34). När blocken väl är på plats kostar skrivningen av varje fil (data synkade till disk, ett namnbyte, händelser i liggaren) några millisekunder på dessa nätverksblockvolymer, vilket begränsar varje källa till några hundra filer i sekunden.

Med båda läsarna samtidigt var Warszawa lika snabbt som ensamt, och Amsterdams två körningar skilde sig åt (202 s och 110 s): läsarnas block hämtas från den enhet som svarar först, och den ena körningen väntade mer på den andra läsaren än den andra körningen gjorde. Bucketen, uppmätt med båda läsarna tre timmar senare, levererade 64 filer i sekunden till Amsterdam och 53 till Warszawa: nästan dubbelt så mycket som den gav enskilda läsare i den tidigare sessionen. Dess hastighet beror mer på tiden på dygnet än på antalet läsare.

Komprimerbar text

512 MiB loggrader, lagrade som 138 MiB. Färre byte färdas, så en läsare får mer fil per sekund än med slumpmässiga data.

Peer-to-peer (från skrivaren i Paris) S3-bucket i Paris (MB/s, mer är bättre)

Läsare	Peer-to-peer: tid	MB/s	S3: tid	MB/s	P2P mot S3
Amsterdam, ensam	32 s (33 s / 31 s)	16.7	36 s (21 s / 52 s)	18.1	1.1× snabbare
Warszawa, ensam	74 s (70 s / 79 s)	7.2	32 s (32 s / 32 s)	16.7	2.3× långsammare
Amsterdam, båda samtidigt	32 s (32 s / 31 s)	16.9	31 s (23 s / 39 s)	18.4	1.0× långsammare
Warszawa, båda samtidigt	66 s (63 s / 69 s)	8.1	63 s (28 s / 98 s)	12.3	1.0× långsammare

Här var bucketen lite snabbare till Amsterdam och mer än dubbelt så snabb till Warszawa. Med båda läsarna samtidigt gav peer-to-peer Amsterdam samma 16.9 MB/s som ensamt och Warszawa 8.1 MB/s, något mer än ensamt; i den första av de två körningarna hämtade Warszawa två tredjedelar av sina block från Amsterdam, i den andra alla från Paris. En enhet som levererar ett block behåller inte den komprimerade kopian: den läser den okomprimerade filen och komprimerar blocket på nytt, med zstd nivå 12, för varje begäran; enheten i Paris använde 31 s CPU-tid per levererade 512 MiB, mot 40 s för 4 GiB slumpmässiga data. Bucketen returnerar det lagrade objektet som det är.

Skrivarens sida

Innan något kan laddas ned delar skrivaren upp sina filer i block, komprimerar, krypterar och lagrar dem. Tre destinationer visar var tiden går: en RAM-disk (bara Varstos eget arbete), maskinens disk (en nätverksblockvolym, där varje objekt skrivs med en synkning till disk) och bucketen.

Datamängd	Destination	Version	Tid	MB/s	CPU (användare + system)	Minnestopp
filer: 10 000 filer, 0.27 GiB	RAM-disk (tmpfs)	uppmätt version	50 s (median av 2)	5.9	12 s (5 + 7)	68 MiB
filer: 10 000 filer, 0.27 GiB	S3-bucket, samma region	uppmätt version	652 s (median av 2)	0.5	21 s (8 + 13)	69 MiB
små: 50 000 filer, 1.36 GiB	RAM-disk (tmpfs)	uppmätt version	255 s (median av 2)	5.7	62 s (27 + 35)	258 MiB
små: 50 000 filer, 1.36 GiB	Lokal disk (nätverksblockvolym)	uppmätt version	468 s	3.1	67 s (27 + 41)	258 MiB
små: 50 000 filer, 1.36 GiB	Lokal disk (nätverksblockvolym)	alpha.8 (före zstd-åtgärden)	515 s	2.8	109 s (31 + 78)	253 MiB
stora: 2 filer, 4.00 GiB	S3-bucket, samma region	uppmätt version	932 s (median av 2)	4.6	80 s (37 + 43)	108 MiB
mycket stora: 5 filer, 12.00 GiB	Lokal disk (nätverksblockvolym)	uppmätt version	418 s	30.9	197 s (85 + 112)	147 MiB
mycket stora: 5 filer, 12.00 GiB	Lokal disk (nätverksblockvolym)	alpha.8 (före zstd-åtgärden)	694 s	18.6	483 s (110 + 373)	137 MiB
text: 128 filer, 0.50 GiB	RAM-disk (tmpfs)	uppmätt version	45 s (median av 2)	12.0	44 s (41 + 2)	68 MiB
text: 128 filer, 0.50 GiB	Lokal disk (nätverksblockvolym)	uppmätt version	56 s	9.6	45 s (42 + 3)	68 MiB
text: 128 filer, 0.50 GiB	Lokal disk (nätverksblockvolym)	alpha.8 (före zstd-åtgärden)	68 s	7.9	56 s (43 + 13)	68 MiB
text: 128 filer, 0.50 GiB	S3-bucket, samma region	uppmätt version	145 s (median av 2)	3.7	45 s (41 + 4)	77 MiB

• Slumpmässiga data kostar omkring 16 s CPU per GiB på dessa kärnor efter zstd-åtgärden (12 GiB: 197 s), mot 40 s per GiB före den.
• Text kostar omkring 85 s CPU per GiB: zstd på nivå 12, en konstant i formatet, är långsam på komprimerbara data; den ger förhållandet 3.7 : 1 som varje senare överföring drar nytta av.
• Små filer begränsas inte av CPU:n ens på en RAM-disk: 10 000 filer tog 50 s, varav 12 s CPU. Enhetens logiska klocka skrivs till disk, med två synkningar, för varje uppladdad fil. Ännu inte åtgärdat.
• Bucketen är överlägset långsammast: varje block är en HEAD och en PUT, efter varandra. 10 000 filer tog 622 s och 681 s, 4 GiB 578 s och 1 287 s de två dagarna. Uppladdningar sker ännu inte parallellt.

Åtgärdat på vägen

Mätningen var också en jakt på flaskhalsar. Dessa ändringar finns i de uppmätta versionerna, var och en med ett test:

Problem	Åtgärd	Före	Efter
En nedladdning hämtade ett block i taget: varje block väntade en hel rundresa innan nästa begärdes.	Upp till åtta block i en fil samtidigt på väg, från andra enheter eller lagringsplatser, i ett glidande fönster; de kontrolleras och skrivs fortfarande i ordning. S3-klienten håller tillräckligt många vilande anslutningar för dem.	Text från bucketen till Warszawa: 122 s (4.4 MB/s)	27.8 s (19.4 MB/s), 4.4 gånger snabbare (enskilda körningar; steg på vägen: fasta omgångar om åtta 104 s, med vilande anslutningar kvar 61 s)
Små filer gick en i taget: varje fil är ett block, så fönstret ovan gällde aldrig.	En hämtning hämtar blocken för upp till 32 kommande filer med ett block var tillsammans (10 okt).	10 000 filer från bucketen till Warszawa: 596 s (17 filer/s)	294 s (34 filer/s)
Peer-to-peer-servern för HTTP besvarade en begäran i taget, så åtta samtidiga begäranden köade hos servern.	Åtta begäranden besvaras samtidigt.	Stora filer peer-to-peer till Amsterdam: 363 s (11.8 MB/s), en körning	159 s (27.0 MB/s)
En ny zstd-kontext skapades för varje block; dess tabeller allokerades och nollställdes varje gång, vilket var mer arbete än att komprimera blocket.	En kontext per tråd som återanvänds (utdata är identiska byte för byte, vilket ett test kontrollerar).	12 GiB till lokal disk: 694 s, 483 s CPU	418 s, 197 s CPU (enskilda körningar)
S3-klienten vägrade alla svar över 10 MiB. Efter en uppladdning av några tusen filer var liggarens batch 13 MB, och ingen annan enhet kunde ansluta eller synkronisera.	Svar på upp till 2 GiB läses.	Anslutningen misslyckades	Anslutningen fungerar; test med ett objekt på 12 MiB
Bakgrundstjänsten behandlade varje öppnad fil som en ändring: att leverera block till andra enheter, ett säkerhetskopieringsverktyg eller ett filvisningsprogram startade en fullständig synkronisering med några sekunders mellanrum.	Att öppna och läsa är inga ändringar; att stänga en fil som öppnats för skrivning är det fortfarande.	90 synkroniseringar på 11 minuter medan filer lästes	Läsning av alla 10 000 filer: ingen extra synkronisering
Samtidiga begäranden öppnade var och en sin egen QUIC-anslutning till en enhet som de ännu inte hade någon anslutning till.	Ett anslutningsförsök per adress; de andra väntar och delar på det (ett test kontrollerar en enda anslutning för en hel hämtning).	Hittat vid test av QUIC (nedan)
En kvarhållen QUIC-anslutning till en enhet som hade startats om fick varje begäran över den att misslyckas, och enheten föll permanent tillbaka till nästa väg.	Anslut på nytt en gång och fråga igen.	Hittat vid test av QUIC (nedan)
Begäranden som blev klara på en gammal väg kunde ångra ett byte till en bättre väg som en annan begäran just hade gjort.	Ett sent svar behåller den aktuella vägen.	Hittat vid test av QUIC (nedan)

Provat och återställt: QUIC först

Eftersom TCP-vägen öppnar en anslutning per block såg QUIC ut som botemedlet: Varsto talar redan QUIC med enheter bakom NAT, med en anslutning per enhet och en ström per begäran. Den 10 oktober ändrades vägordningen så att QUIC provas före TCP för adresser utanför det lokala nätverket. Det var långsammare på dessa maskiner och använde mer än dubbelt så mycket CPU-tid:

Stora filer, peer-to-peer	TCP först (behållet)	QUIC först (återställt)
Amsterdam	159 s, 27.0 MB/s; läsaren 38 s CPU, Paris 40 s	230 s, 18.7 MB/s (229 s / 230 s); läsaren 98 s CPU, Paris 88 s
Warszawa	423 s, 10.2 MB/s	466 s, 9.2 MB/s (en körning); läsaren 130 s CPU

Så TCP förblir förstahandsvalet och QUIC är fortsatt vägen genom NAT. Var QUIC-vägen förlorar sin tid hann inte utredas; värden tappade inga UDP-paket. Experimentet avslöjade också en brist som ännu inte är åtgärdad: en enhets peer-tabell byggs innan en synkronisering läser enhetsregistret, så en enhet som just har anslutit nekas över QUIC av de andra enheterna fram till deras nästa synkronisering (över TCP betjänas den direkt).

Fortfarande långsamt, och varför

• En TCP-anslutning per block på peer-to-peer-vägen (i de versioner som mättes här). Varje begäran betalade en handskakning och en ny slow start, vilket var det som begränsade Warszawa. Ändrat sedan dess: anslutningar till en enhet hålls nu öppna mellan begärandena, upp till 32 begäranden är på väg samtidigt, fönstret följer den uppmätta genomströmningen, och block som lagrats okomprimerade komprimeras inte längre på nytt när de levereras. På en maskin med en nätverksnamnrymd som emulerade en rundresa på 32 ms (Paris–Warszawa) vid 800 Mbit/s, som klarade 62 MB/s i en TCP-ström och 81 MB/s i 16, gick peer-to-peer från 10.4 till 44.7 MB/s för okomprimerbara data och från 11.3 till 38.6 MB/s för text, och bucketen (levererad av rclone serve s3 över samma förbindelse) från 41.5 till 45.5 och från 39.1 till 52.8 MB/s (medelvärden av två körningar). Detta är lokala mätningar, inte en upprepning av körningarna ovan; mätskriptet är scripts/bench/netem-local.sh.
• Att leverera komprimerbara data kostar CPU, eftersom varje begäran komprimerar blocket på nytt; därför ligger text peer-to-peer under bucketen i emuleringen. Block som komprimerats för en enhet behålls nu i minnet (64 MiB som standard) för nästa enhet som frågar, till exempel när flera enheter kommer ikapp samtidigt.
• En nedladdning med peer-to-peer påslaget använder nu även bucketen när den svarar snabbare, i proportion till dess hastighet. I emuleringen delade båda på en förbindelse, så att använda båda var inte snabbare än vardera för sig (44.4 MB/s för båda datamängderna); över verkliga nätverk skiljer sig de två vägarna åt.
• Att skriva många små filer kostar en disksynkning per fil hos läsaren, och hos skrivaren två synkningar per fil för den logiska klockan.
• Uppladdningar till en bucket sker ett block i taget, med en HEAD före varje PUT.
• Liggaren växer med omkring 1 KB per block: uppladdningen av mängden på 4 GiB skrev en liggarbatch på 13 MB, som varje enhet läser när den ansluter.

När peer-to-peer vinner, och när bucketen gör det

Varsto använder båda med avsikt, och mätningarna visar varför.

• Peer-to-peer kräver en annan enhet online. Läsarna kunde hämta bara för att en enhet som hade blocken var igång. Bucketen finns alltid där: en hopfälld bärbar dator, en telefon i en låda, enheter som aldrig är online samtidigt synkroniserar alla ändå genom den. Därför har ett valv alltid minst en lagringsplats, och därför ligger fillistorna och liggaren kvar i den.
• Mellan närliggande enheter vinner peer-to-peer: 2.7 gånger snabbare för många små filer till Amsterdam än bucketen under samma session (under en senare session kom bucketen nära), lite snabbare och betydligt jämnare för stora filer. I ett lokalt nätverk är rundresan en bråkdel av en millisekund.
• Enheter som redan har data delar med sig av dem. Med två läsare hämtade Warszawa de flesta av sina block från Amsterdam; den första enheten som synkroniserar blir en källa för nästa, och skrivarens uppladdning skonas.
• Mellan avlägsna enheter och för komprimerbara data vann bucketen på dessa förbindelser: stora filer och text till Warszawa, text till Amsterdam med liten marginal. Orsakerna är kända (en anslutning per block, ny komprimering vid leverans) och ligger inte i nätverket: förbindelsen till Warszawa klarade 777 Mbit/s i en ström.
• Bucketen skalar till många läsare utan att belasta någons uppladdning; en enhet i hemmet som betjänar många andra begränsas av sin uppladdningshastighet, om inte läsarna hjälper varandra som ovan.
• Peer-to-peer kostar ingenting per gigabyte och lämnar ingen kopia hos någon leverantör. Data går från din enhet till din enhet; bucketen behöver blocken bara för de enheter som är offline när andra vill ha dem.

Kostnad

Scaleways publika prislista (läst den 9 oktober 2026, regionen Paris, exklusive moms): Object Storage Standard Multi-AZ €0.000022 per GB-timme (omkring €0.016 per GB-månad), begäranden ingår, inkommande trafik ingår, utgående trafik gratis för de första 75 GB i månaden och därefter €0.01 per GB. Överföringar mellan regioner (Paris – Amsterdam, Paris – Warszawa) räknas som utgående trafik; inom en region är de gratis.

En läsare i Amsterdam som laddar ned mängden på 4 GiB från bucketen i Paris kostar alltså omkring €0.04 när de fria 75 GB är förbrukade, och ett hushåll som synkroniserar 500 GB i månaden till enheter utanför bucketens region betalar omkring €4 i månaden för utgående trafik. Peer-to-peer flyttar samma byte över enheternas egna anslutningar och lägger inget till lagringsräkningen. Andra leverantörer tar mer betalt för utgående trafik eller per begäran; metoden ovan gäller för dem oförändrad. Maskinerna för den här mätningen (tre instanser à €0.147 i timmen, omkring sju och en halv timme under de två dagarna) kostade omkring €3.50.

Begränsningar i den här mätningen

• Två dagar, två versioner. Körningarna med stora filer från enskilda läsare och en del av bucketkörningarna är från den 9 oktober, resten från den 10 oktober; ändringarna mellan dem berör inte de jämförda fallen (se ovan). Bucketens hastighet skilde sig mellan dagarna.
• Molnmaskiner, inte hem. Förbindelser i datacenter, publika adresser på gränssnittet, ingen NAT, inget wifi. Hemma går peer-to-peer-vägen över internet oftast via QUIC genom en NAT med hålslagning, vilket dessa körningar bara mätte i det återställda experimentet; hemmets uppladdningshastighet skulle ofta vara gränsen.
• Tre regioner hos en leverantör, i Europa. Bucketen och maskinerna delar leverantör och stamnät; andra leverantörer och längre avstånd ger andra resultat.
• Nätverksblockvolymer gör varje disksynkning långsam (millisekunder), vilket väger tungt för små filer; en bärbar dators SSD synkar snabbare.
• Två körningar per fall är få; bucketens resultat varierade med upp till 58 % mellan upprepningar för små filer och med en faktor 3.5 för text, och bucketens hastighet för små filer nästan fördubblades mellan två sessioner samma dag.
• Alfaprogramvara. Format och standardvärden kan fortfarande ändras, och det kommer även de här siffrorna att göra.

Upprepa: scripts/bench/p2p-bench.py skapar maskinerna och bucketen med Scaleways kommandoradsverktyg, kör varje steg, skriver results.jsonl och raderar allt igen; report.py och page.py gör om resultaten till sammanfattningen och tabellerna på den här sidan.