JCIFS: truy xuất tệp quá chậm để có thể sử dụng được

Question

Tôi vừa thử nghiệm JCIFS để truy cập vào các chia sẻ Windows. Nó rất chậm đến mức hoàn toàn không thể sử dụng được.

import jcifs.smb.*; 

class First { 
    public static void main(String[] args) throws Exception { 
    try { 
     //jcifs.Config.setProperty("jcifs.netbios.wins", "192.168.1.220"); 
     NtlmPasswordAuthentication auth = new NtlmPasswordAuthentication("domain.com", "Administrator", "password"); 

     SmbFile f = new SmbFile("smb://10.17.15.12/Share/xml/file.xml", auth); 
     SmbFileInputStream in = new SmbFileInputStream(f); 
     byte[] b = new byte[8192]; 
     int n; 
     while((n = in.read(b)) > 0) { 
     System.out.write(b, 0, n); 
     } 
    } catch (SmbException smbe) { 
     System.err.println(smbe.getNtStatus()); 
     System.err.println(smbe.toString()); 
     System.err.println(smbe.getCause()); 
    } 
    } 
} 

Phải mất rất nhiều thời gian cho lần xuất đầu tiên đến và lần đọc tiếp theo cũng rất chậm. Bất kỳ ý tưởng làm thế nào để sử dụng nó? Bất kỳ lựa chọn thay thế nào mà tôi có thể viết mã Java để truy cập vào cổ phiếu Windows theo cách di động cũng được chào đón

Answer 1

Tôi tìm thấy ở đâu đó SmbFileInputStream không tự đệm và do đó lý do làm chậm. Gói SmbFileInputStream trong BufferedInputStream đã giải quyết được vấn đề.

SmbFile sFile = new SmbFile(path, authentication); 

BufferedInputStream buf = new BufferedInputStream(new SmbFileInputStream(sFile)); 

Answer 2

Nếu bạn có thể dựa vào "cái gì khác" để gắn kết chia sẻ làm thư mục cục bộ cho bạn, sau đó đọc tệp trong gắn kết chia sẻ trong Java nên được di động.

Ngay cả khi đây không phải là giải pháp thực sự, sẽ rất đáng thử để xem bạn có nhận được tốc độ đọc nhanh hơn hay không. Tốc độ đọc nhanh hơn đáng kể có thể thay đổi suy nghĩ của bạn về tầm quan trọng tương đối của tính di động. Và nếu bạn không tăng tốc đáng kể, bạn sẽ biết rằng JCIFS không đổ lỗi ...

Answer 3

Trong trường hợp của riêng tôi, việc đẩy tệp vào chia sẻ Windows qua JCIFS quá chậm để có thể sử dụng được.

Giải pháp bật ra được xác định tài sản

 
-Djcifs.resolveOrder=DNS 

Các default inclusion của BCAST - phát sóng một tên truy vấn NetBIOS để 255.255.255.255 - đã không cần thiết dẫn đến một sự chậm trễ kéo dài. (Liên kết ở trên được đóng khung từ top-level API docs.)

Answer 4

Điều tôi nhận thấy là jCIFS thực hiện "một cái gì đó" (afair jcifs.smb.SmbTransport.checkStatus(..)) cho mỗi đoạn nó đọc - tức là đối với mỗi đoạn được đọc vào bộ đệm. Điều đó có nghĩa là sử dụng BufferedInputStream có thể thực sự tăng tốc, nhưng vấn đề thực sự vẫn tồn tại, nó chỉ không xảy ra thường xuyên như trước và do đó có tác động thấp hơn đến thời gian tổng thể ..

Nó giúp rất nhiều để thiết lập "jcifs.util .loglevel = 3 "và có giao diện thực sự sai!

Trong trường hợp của tôi, tôi đã phải đặt "jcifs.smb.client.dfs.disabled=false" cuối cùng, bằng "jcifs.resolveOrder=DNS" không giúp ích gì ..

Answer 5

Ngay cả với các đề xuất hiện có tôi vẫn thấy JCIFS quá chậm để phát trực tuyến video qua mạng cục bộ của mình. Nó dường như được làm với chi phí cho mỗi bộ đệm đọc từ mạng, thậm chí đọc vào bộ đệm lớn JCIFS chính nó đã có một kích thước bộ đệm giới hạn đó là vấn đề.

Nếu bạn nhìn vào https://jcifs.samba.org/src/patches/ có một bản vá, LargeReadWrite.patch. Bạn sẽ cần phải áp dụng các bản vá và xây dựng lại mã để sử dụng nó, nhưng nó đã tạo ra một sự khác biệt lớn đối với tôi.

Answer 6

Giải pháp được thêm vào bởi @ Xolve0 cũng làm việc cho tôi. Vấn đề bộ đệm trong SmbFileInput cũng có mặt khi cố gắng ghi tệp. Tôi đã sử dụng cùng một BufferedInputStream(new SmbFileInputStream(sFile)) để giảm thời gian thực hiện từ 90 giây xuống dưới một giây đối với tệp văn bản thuần túy.

Cách nhanh chóng để xác định vấn đề cụ thể này là theo dõi thời gian giữa việc mở đường dẫn JCIFS và ghi chính tệp đó.