Små filer kryper över VPN på grund av tur-och-retur-resor, inte hastighet

Kopiera en fil på 2 GB över VPN och överföringen ser bra ut. Kopiera en mapp med tiotusen små dokument och samma förbindelse verkar trasig. Skillnaden är inte en bandbreddsinställning som ändrades mellan de två jobben. Det andra jobbet lägger sin tid på uppsättning, metadata och väntan på svar, och det är tunnelns latens som gör den väntan synlig.

En fil strömmar; en mapp med filer förhandlar

En stor kopiering tillbringar större delen av sitt liv i en läs-och-skrivslinga på några få öppna handtag. Protokollkostnaden betalas en gång per fil, och data rör sig i stora block. Bandbredden dominerar resultatet.

En mappkopiering betalar per fil: skapa, fråga efter attribut, öppna, skriva, stänga och uppdatera mappens metadata. Var och en av dessa är en begäran som väntar på svar innan nästa steg kan fortsätta. Byten är små; koordineringen är det inte.

Därför bevisar en graf med låg länkanvändning nästan ingenting. Länken är ledig eftersom klienten väntar, inte för att tunneln är långsam. En lagringsmatris eller en slutpunktsskanner kan lägga till samma form av fördröjning. Identifiera vilket steg som väntar innan du ändrar någon nätverksinställning.

Tur-och-retur-resor summeras snabbare än byte

Latens är kostnaden för ett beroende utbyte. Om en fil behöver flera seriella utbyten och tunneln lägger till 40 ms i varje riktning, växer kostnaden per fil snabbt. Tiotusen filer gör det till minuter.

Aritmetiken är illustrativ, inte en mätning: en fil kostar inte nödvändigtvis en tur-och-retur, och klienter överlappar en del av arbetet.

Två spakar ändrar summan. Minska antalet beroende utbyten per fil, eller håll fler av dem i gång samtidigt. Det första är en protokoll- eller arbetsbelastningsändring; det andra är samtidighet. Ingen av dem gör en långsam länk snabbare.

Mät arbetsbelastningen, inte länken

Jämför tre jobb med samma slutpunkter och samma åtkomstpolicy: en stor fil, mappen med små filer och den faktiska affärsoperationen. Notera filantal, storleksfördelning, kopieringsverktyg och nätverksförhållanden med varje resultat.

En enda MB/s-siffra utan dessa detaljer kan inte jämföras med någon annans.

Mät latens separat från genomströmning. Ett enkelt tur-och-retur-test till filservern ger siffran som multipliceras över små operationer. Titta sedan på kopieringens begärandemönster i stället för dess medelhastighet. Om hastigheten är låg och länken är ledig ligger flaskhalsen ovanför tunneln.

Ändra jobbet: samtidighet och arkiv

För en auktoriserad masskopiering håller ett verktyg med kontrollerad samtidighet fler begäranden i gång. /MT-alternativet i Robocopy är det vanliga Windows-exemplet. Att lägga till trådar garanterar inte en snabbare kopiering.

Välj ett antal som klienten, servern och lagringen kan klara, och spara jobbloggen och eventuella fel.

Arkivering vid källan och uppackning lokalt tar bort fjärrarbetet per fil. Ta med förberedelse- och uppackningstid i jämförelsen och bekräfta att arkivet bevarar de metadata och behörigheter som jobbet behöver. Ingen av knepen får ett program att samla sina egna filoperationer.

Kontrollera räknaren med ett kontrollerat test

Kör samma jobb två gånger med en variabel ändrad och notera båda siffrorna. Ett kontrollerat test är det enda sättet att veta om en inställning hjälpte eller om nätverket råkade vara lugnare.

Två kommandon ger filantalet och tur-och-retur-baslinjen:

Get-ChildItem \\fileserver.hq.example\\share -Recurse | Measure-Object -Property Length -Sum
ping -n 20 fileserver.hq.example

Kör sedan kopieringen med ett begränsat antal trådar och jämför loggen med föregående körning:

robocopy \\fileserver.hq.example\\share C:\\local /E /MT:16 /LOG:copy.log /TEE

Inaktivera inte SMB-signering, kryptering eller slutpunktsskydd för att förbättra räknaren. De ändringarna byter en säkerhetsegenskap mot en siffra som kanske inte var flaskhalsen. Och håll VPN-transporten åtskild från SMB:s egen transport i dina anteckningar, eftersom en rättelse i den ena inte är bevis för den andra.