Cái nào nhanh hơn và tại sao: chuyển một vài tệp nhỏ hoặc một vài tệp lớn?


17

Tôi sẽ sớm có một thư mục với hàng ngàn tệp, mỗi tệp theo thứ tự vài KB. Tôi sẽ cần chuyển những thứ này qua mạng Windows từ một chia sẻ UNC sang một mạng khác. Nói chung, nhanh hơn là sao chép các tệp qua en masse, hoặc sẽ nhanh hơn để nén chúng (ví dụ: sử dụng 7zip ở chế độ nhanh nhất) và gửi một hoặc một vài tệp lớn? Hoặc không có sự khác biệt trong thực tế?

Câu trả lời:


37

Nhanh hơn là chuyển một tệp lớn thay vì nhiều tệp nhỏ vì chi phí đàm phán chuyển. Việc đàm phán được thực hiện cho mỗi tệp, do đó, việc chuyển một tệp duy nhất cần được thực hiện một lần, chuyển n tệp có nghĩa là cần phải thực hiện n lần.

Bạn sẽ tiết kiệm cho mình rất nhiều thời gian nếu bạn zip trước khi chuyển tiền.


1
vi.wikipedia.org/wiki/Slow-start cũng ủng hộ các tệp lớn.
Chỉ huy Keen

4
Xem xét rằng nén cũng sẽ mất thời gian. Nếu dữ liệu của bạn không thể được nén (ví dụ JPEG, ZIP, JAR và các định dạng đã nén khác), bạn chỉ nên TAR chúng (hoặc ZIP mà không nén). Điều này sẽ tiết kiệm thời gian CPU cho nỗ lực vô nghĩa để nén thêm dữ liệu của bạn.
Daniel Schneller

Nhiều tệp nhỏ đó sẽ gây cho bạn rất nhiều đau đớn - ở giữa các gói nhỏ và thực hiện bắt tay SMB cho từng tệp, việc nén có thể sẽ giúp giảm 60% thời gian sao chép của bạn.
dùng2278

+1 cho TAR vì bạn có thể sao chép / trích xuất một phần lưu trữ.
Cristian Vat

Câu trả lời này là đúng, nhưng trên Windows 7 (ít nhất) có một lỗi được biết nơi sao chép cùng một tập hợp chính xác các tập tin trên XP được nhiều nhanh hơn trên Windows 7: social.technet.microsoft.com/Forums/en-US/ w7itproperf / thread / ...
tbone

5

Jon Cahill là rất chính xác, một tập tin duy nhất sẽ nhanh hơn. Tuy nhiên, bạn nên nhớ rằng nếu có bất kỳ sự mất ổn định nào trong kết nối, các tệp riêng lẻ (hoặc các nhóm có kích thước trung bình trong tệp zip) có thể tốt hơn, vì nếu chuyển không thành công, bạn sẽ phải bắt đầu lại, trong khi với nhiều các tệp bạn sẽ phải làm lại tệp cuối cùng đã bắt đầu


5
Trừ khi giao thức chuyển có tiếp tục.
Unkwntech

1

Nhiều tệp nhỏ cũng sẽ tốn kém hơn để ghi vào hệ thống tệp so với một tệp lớn. Nó cần phải làm những việc như:

  • Kiểm tra tên tệp là duy nhất
  • Viết ra mục nhập bảng

Khi bạn nhận được càng nhiều tệp trong một thư mục, điều này có thể trở nên khá tốn kém. Và mỗi bước này có thể thêm độ trễ cho quá trình sao chép và làm chậm toàn bộ sự việc.


1
Tôi đoán rằng anh ta vẫn sẽ cần tất cả các tệp nhỏ trong hệ thống đích, vì vậy anh ta có thể sẽ phải giải nén zip sau đó, tức là hệ thống tệp sẽ vẫn phải thực hiện công việc. Tuy nhiên, việc gửi tệp lớn và giải nén vẫn sẽ nhanh hơn nhiều so với việc chuyển tất cả các tệp nhỏ qua mạng.
BlaM

@BlaM, như tôi đã nói trong câu trả lời, tất cả đều bắt nguồn từ độ trễ. Nếu độ trễ mạng được thêm vào mỗi hoạt động của CreatFile, tổng thời gian có thể lâu hơn nhiều. Nếu bản sao đủ thông minh để tạo đồng thời các tệp có lẽ nó sẽ không ảnh hưởng đến hoạt động.
Luke Quinane

0

Kích thước gói trung bình so với kích thước tệp trung bình có lẽ rất quan trọng ở đây. Với nhiều tệp nhỏ, bạn có thể thấy mình đang gửi nhiều gói nhỏ. Các gói nhỏ vẫn phải chịu phí TCP; Kết quả là bạn có thể tăng gấp đôi lưu lượng truy cập.

Các hệ thống hiện đại và thậm chí những hệ thống tương đối cổ xưa có thể gửi nhiều tệp qua một kết nối TCP, tránh chi phí cho cái bắt tay đó.


0

Chỉ là những gì tôi đã tìm thấy, nhưng nếu bạn muốn chuyển nhanh hơn, hãy bắt đầu chuyển từ máy tính cục bộ và sao chép vào ổ đĩa cục bộ.

Tức là sao chép \ computer1 \ myshare sang c: \ files \ myshare, không sử dụng máy tính thứ ba và sao chép từ \ computer1 \ myshare sang \ computer2 \ mynewshare.


0

Cũng đáng nhớ rằng việc lựa chọn giao thức ảnh hưởng đến toàn bộ thời gian hoàn thành - ví dụ, đối với các tệp FTP từ máy chủ này sang máy chủ khác, có thể nhanh hơn đáng kể so với sử dụng chia sẻ tệp windows (tất nhiên, những thứ như quyền miền và tương tự cũng vậy bị mất, nhưng trong một số tình huống, đây có thể là một sự đánh đổi chấp nhận được - Rốt cuộc, những điều này cũng sẽ bị mất bằng cách nén / giải nén)

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.