Co jest szybsze i dlaczego: przesyłanie kilku małych plików lub kilku dużych plików?


17

Wkrótce będę miał folder z tysiącami plików, każdy plik rzędu kilku KB. Będę musiał przenieść je przez sieć Windows z jednego udziału UNC do drugiego. Zasadniczo, czy szybciej jest po prostu skopiować pliki masowo, czy też szybciej byłoby je skompresować (np. Używając 7zip w trybie najszybszym) i wysłać jeden lub kilka dużych plików? Czy nie ma różnicy w praktyce?

Odpowiedzi:


37

Szybsze jest przesyłanie pojedynczego dużego pliku zamiast wielu małych plików ze względu na narzut związany z negocjowaniem transferu. Negocjacja jest wykonywana dla każdego pliku, więc przesłanie pojedynczego pliku musi być wykonane raz, przesłanie n plików oznacza, że ​​należy to zrobić n razy.

Zaoszczędzisz sobie dużo czasu, jeśli najpierw spakujesz zip przed transferem.


1
en.wikipedia.org/wiki/Slow-start również preferuje duże pliki.
Komandor Keen

4
Weź pod uwagę, że kompresja również wymaga czasu. Jeśli twoich danych nie można skompresować (np. JPEG, ZIP, JAR i inne już skompresowane formaty), powinieneś je tylko TAR (lub ZIP bez kompresji). Pozwoli to zaoszczędzić czas procesora na bezcelową próbę dalszej kompresji danych.
Daniel Schneller

Tak wiele małych plików sprawi ci dużo bólu - pomiędzy drobnymi pakietami i wykonaniem uścisku dłoni SMB dla każdego z nich, zipowanie prawdopodobnie skróci o 60% czas kopiowania.
user2278

+1 dla TAR, ponieważ możesz skopiować / wyodrębnić częściowe archiwum.
Cristian Vat

Ta odpowiedź jest poprawna, ale w Windows 7 (przynajmniej) istnieje znany błąd, w którym kopiowanie dokładnie tego samego zestawu plików na XP jest znacznie szybsze niż na Windows 7: social.technet.microsoft.com/Forums/en-US/ w7itproperf / thread /…
tbone

5

Jon Cahill ma rację, pojedynczy plik będzie szybszy. Należy jednak pamiętać, że w przypadku niestabilności połączenia poszczególne pliki (lub średnie grupy w plikach zip) mogą być lepsze, ponieważ jeśli transfer się nie powiedzie, musisz zacząć od nowa, podczas gdy z wieloma pliki będą musiały ponownie wykonać ostatnio uruchomiony plik


5
Chyba że protokół przesyłania zostanie wznowiony.
Unkwntech

1

Dużo małych plików będzie również droższych do zapisu do systemu plików niż pojedynczy duży plik. Musi robić takie rzeczy jak:

  • Sprawdź, czy nazwa pliku jest unikalna
  • Zapisz wpis w tabeli plików

Ponieważ coraz więcej plików w katalogu może być dość kosztowne. Każdy z tych kroków może zwiększyć opóźnienie procesu kopiowania i spowolnić proces.


1
Myślę, że nadal będzie potrzebował wszystkich małych plików w systemie docelowym, więc prawdopodobnie będzie musiał później rozpakować zip, tzn. System plików nadal będzie musiał wykonać pracę. Jednak wysyłanie dużego pliku i rozpakowywanie będzie nadal znacznie szybsze niż przesyłanie wszystkich małych plików przez sieć.
BlaM

@BlaM, jak powiedziałem w odpowiedzi, wszystko sprowadza się do opóźnienia. Jeśli opóźnienie sieci zostanie dodane do każdej operacji CreateFile, całkowity czas może być znacznie dłuższy. Jeśli kopia jest wystarczająco inteligentna, aby jednocześnie tworzyć pliki, być może nie wpłynie to na działanie.
Luke Quinane

0

Średni rozmiar pakietu w stosunku do średniego rozmiaru pliku ma prawdopodobnie tutaj kluczowe znaczenie. Z dużą ilością małych plików możesz wysyłać wiele małych pakietów. Małe pakiety nadal obciążają TCP; w rezultacie możesz podwoić natężenie ruchu.

Nowoczesne systemy, a nawet stosunkowo stare, mogą wysyłać wiele plików za pomocą jednego połączenia TCP, unikając kosztów tego uścisku dłoni.


0

Właśnie to znalazłem, ale jeśli chcesz szybszego transferu, zainicjuj transfer z komputera lokalnego i skopiuj na dysk lokalny.

Tj. Skopiuj \ komputer1 \ myshare do c: \ files \ myshare, nie używaj trzeciego komputera i skopiuj z \ komputer1 \ myshare do \ komputer2 \ mynewshare.


0

Warto również pamiętać, że wybór protokołu wpływa na całkowity czas ukończenia - na przykład przesyłanie plików FTP z jednego hosta do drugiego może być zauważalnie szybsze niż korzystanie z udostępniania plików w systemie Windows (oczywiście rzeczy takie jak uprawnienia domeny i tym podobne są również zgubiony, ale w niektórych sytuacjach może to być akceptowalny kompromis - w końcu zostaną one również utracone przez skompresowanie / rozpakowanie)

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.