Visual Studio chậm trên thư mục chia sẻ VPN: vì sao lưu lại thành những chuyến khứ hồi

Một giải pháp mở trong một giây từ đĩa cục bộ cần ba mươi giây để mở từ thư mục chia sẻ truy cập qua đường hầm. Đường hầm hiếm khi là nguyên nhân tự thân. Điều thay đổi là các thao tác từng là lệnh gọi cục bộ trở thành những chuyến khứ hồi đồng bộ, và trình soạn thảo thực hiện vài thao tác trong số đó trước khi cửa sổ hiện ra. Cơ chế dưới đây giải thích vì sao mỗi thao tác đều đắt và thao tác nào có thể bỏ.

Trình soạn thảo làm gì khi một tệp đang mở

Trình soạn thảo có theo dõi thay đổi giữ một đăng ký trên mỗi tệp đang mở. Ổ cục bộ phục vụ đăng ký đó từ hệ thống tệp mà không cần mạng. Qua thư mục chia sẻ, cùng tính năng đó có thể thoái hóa thành những lần đọc siêu dữ liệu lặp lại, vì mô hình thông báo không hoạt động giống nhau qua SMB. Tắt theo dõi thay đổi là thử nghiệm đầu tiên hợp lý, vì nó loại bỏ cả một lớp yêu cầu mà không chạm vào đường hầm.

Hệ thống dự án thêm lưu lượng của riêng nó. Tải một giải pháp sẽ liệt kê thư mục, đọc tệp dự án và có thể dò SDK hoặc gói, và mỗi lần dò là một chuyến khứ hồi khi đường dẫn ở xa. Một giải pháp nhiều dự án nhân số đó lên, vì thế thời gian mở tăng nhanh hơn kích thước tệp gợi ý.

Các tra cứu shell hết hạn trước khi menu xuất hiện

Windows đóng góp nguồn treo thứ hai không liên quan gì đến IDE. Explorer và các tiện ích shell của nó phân giải lại máy in, ổ đĩa được ánh xạ và lối tắt đã dùng trước đây mỗi khi menu ngữ cảnh mở ra. Khi những mục tiêu đó nằm trên mạng mà đường hầm không tới được, mỗi lần phân giải bị chặn cho đến khi hết thời gian chờ, và chỉ khi đó menu mới được vẽ. Đó là lý do nhấp chuột phải có thể treo vài giây trong khi bản thân tệp vẫn mở bình thường.

Hãy xóa các ánh xạ chết và hàng đợi máy in, hoặc chỉ giữ những thứ tồn tại trên mạng bạn thực sự đang ở. Lập luận tương tự bao trùm mọi thứ phân giải đường dẫn ở chế độ nền, kể cả danh sách tệp gần đây và thư mục được ghim.

net use
Get-Printer | Select-Object Name, PortName
Measure-Command { Get-ChildItem \files\proj | Out-Null }

Vì sao bản làm việc cục bộ thắng

Làm việc trực tiếp trên thư mục chia sẻ là cách bố trí tệ nhất cho vòng lặp chỉnh sửa, biên dịch và kiểm thử, vì trình soạn thảo, trình biên dịch và ứng dụng khách quản lý phiên bản mỗi bên đọc những tệp từ xa đó riêng rẽ. Mỗi bên trả chuyến khứ hồi của mình, và một lần biên dịch trả một lần cho mỗi tệp. Bản sao cục bộ với việc đẩy qua kho lưu trữ thay một lũ giao cắt nhỏ bằng một giao cắt có chủ đích. Đường truyền không tốt hơn; số lần giao cắt đã sụp đổ.

Đó là thay đổi cấu trúc chứ không phải bài tập tinh chỉnh, và chính vì thế nó hiệu quả khi các thiết lập đường hầm không hiệu quả. Nó cũng làm chế độ hỏng trở nên rõ ràng: nếu biên dịch vẫn chậm với bản sao cục bộ, thì thư mục chia sẻ chưa bao giờ là vấn đề.

Di chuyển lịch sử như một đối tượng duy nhất

Khi bản thân kho lưu trữ phải vượt qua đường hầm, hãy gửi lịch sử trong một đối tượng duy nhất thay vì đi qua nó. Gói là một tệp và do đó một lần truyền, trong khi một checkout đi qua hàng nghìn đối tượng rời tốn hàng nghìn giao cắt. Mercurial và Git đều hỗ trợ hình thức đó.

hg bundle --base 9f2c1a7e outgoing.hg
hg unbundle outgoing.hg
git bundle create repo.bundle main
git clone repo.bundle repo

Bản sửa đổi cơ sở là phần cần nhắm đúng, vì nó quyết định bao nhiêu lịch sử sẽ đi. Đóng gói mọi thứ vẫn chạy nhưng lãng phí đường truyền, trong khi đóng gói từ thay đổi chung cuối cùng chỉ di chuyển những gì phía kia thiếu.

Đo ba thao tác trước khi đổ lỗi cho băng thông

Hãy đo ba thứ riêng rẽ: một tệp nhỏ được mở, một thư mục được liệt kê, một lần lưu hoàn tất. Nếu cả ba đều chậm tương ứng với số tệp, chi phí là những chuyến khứ hồi. Nếu một cái kẹt trong khi những cái khác ổn, hãy nghi ngờ thời gian chờ với một tài nguyên không tới được chứ không phải băng thông. Ghi lại máy đang ở mạng nào trong mỗi lần chạy, vì một máy tính xách tay kết nối lại với hồ sơ khác có thể thay đổi câu trả lời giữa các lần thử.

Sau đó lặp lại đúng ba phép đo đó với một bản sao cục bộ của dự án. Khác biệt chính là giá của thư mục chia sẻ, và đó là con số cần nêu khi ai đó đề xuất một đường truyền nhanh hơn như giải pháp.