Małe pliki pełzną przez VPN z powodu podróży w obie strony, a nie prędkości

Skopiuj jeden plik o rozmiarze 2 GB przez VPN, a transfer wygląda dobrze. Skopiuj folder z dziesięcioma tysiącami małych dokumentów, a to samo łącze wygląda na zepsute. Różnicą nie jest ustawienie przepustowości, które zmieniło się między zadaniami. Drugie zadanie spędza czas na konfiguracji, metadanych i czekaniu na odpowiedzi, a to opóźnienie tunelu czyni to oczekiwanie widocznym.

Jeden plik jest strumieniowany; folder plików negocjuje

Duże kopiowanie spędza większość życia w pętli odczytu i zapisu na kilku otwartych uchwytach. Narzut protokołu jest płacony raz na plik, a dane przemieszczają się w dużych blokach. Wynikiem rządzi przepustowość.

Kopiowanie folderu płaci za każdy plik: utworzenie, zapytanie o atrybuty, otwarcie, zapis, zamknięcie i aktualizację metadanych katalogu. Każda z tych czynności to żądanie, które czeka na odpowiedź, zanim następny krok może ruszyć. Bajty są drobne; koordynacja nie.

Dlatego wykres niskiego wykorzystania łącza nie dowodzi prawie niczego. Łącze jest bezczynne, bo klient czeka, a nie dlatego, że tunel jest wolny. Macierz pamięci masowej lub skaner punktów końcowych może dodać taki sam kształt opóźnienia. Ustal, który etap czeka, zanim zmienisz jakiekolwiek ustawienie sieci.

Podróże w obie strony sumują się szybciej niż bajty

Opóźnienie to koszt jednej zależnej wymiany. Jeśli plik wymaga kilku sekwencyjnych wymian, a tunel dodaje 40 ms w każdą stronę, koszt na plik rośnie szybko. Dziesięć tysięcy plików zamienia to w minuty.

Arytmetyka jest poglądowa, nie pomiarowa: plik nie musi kosztować jednej podróży w obie strony, a klienci nakładają na siebie część pracy.

Dwie dźwignie zmieniają sumę. Zmniejsz liczbę zależnych wymian na plik albo utrzymuj więcej z nich jednocześnie w toku. Pierwsza to zmiana protokołu lub obciążenia; druga to współbieżność. Żadna nie czyni wolnego łącza szybszym.

Mierz obciążenie, a nie łącze

Porównaj trzy zadania z tymi samymi punktami końcowymi i tą samą polityką dostępu: jeden duży plik, folder małych plików i rzeczywistą operację biznesową. Zapisz liczbę plików, rozkład rozmiarów, narzędzie do kopiowania i warunki sieciowe przy każdym wyniku.

Pojedynczej liczby w MB/s bez tych szczegółów nie można porównać z niczyją inną.

Mierz opóźnienie osobno od przepustowości. Prosty test podróży w obie strony do serwera plików daje liczbę, która mnoży się przez małe operacje. Potem obserwuj wzorzec żądań kopiowania, a nie jego średnią prędkość. Jeśli prędkość jest niska, a łącze bezczynne, wąskie gardło jest powyżej tunelu.

Zmień zadanie: współbieżność i archiwa

Do dozwolonego kopiowania zbiorczego narzędzie z kontrolowaną współbieżnością utrzymuje więcej żądań w toku. Opcja /MT w Robocopy to typowy przykład w Windows. Dodawanie wątków nie gwarantuje szybszego kopiowania.

Wybierz liczbę, którą klient, serwer i macierz mogą wytrzymać, i zachowaj dziennik zadania oraz wszelkie błędy.

Archiwizacja u źródła i rozpakowanie lokalnie usuwają zdalną pracę na plik. Uwzględnij w porównaniu czas przygotowania i rozpakowania oraz potwierdź, że archiwum zachowuje metadane i uprawnienia potrzebne zadaniu. Żaden z tych trików nie zmusza aplikacji do grupowania własnych operacji na plikach.

Sprawdź licznik kontrolowanym testem

Uruchom to samo zadanie dwa razy ze zmienioną jedną zmienną i zapisz obie liczby. Kontrolowany test to jedyny sposób, by wiedzieć, czy ustawienie pomogło, czy sieć była przypadkiem spokojniejsza.

Dwie komendy dają liczbę plików i linię bazową podróży w obie strony:

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

Następnie uruchom kopiowanie z ograniczoną liczbą wątków i porównaj dziennik z poprzednim uruchomieniem:

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

Nie wyłączaj podpisywania SMB, szyfrowania ani ochrony punktów końcowych, aby poprawić licznik. Te zmiany wymieniają właściwość bezpieczeństwa na liczbę, która może nie była wąskim gardłem. I trzymaj transport VPN osobno od własnego transportu SMB w notatkach, bo poprawka w jednym nie jest dowodem na drugie.