java JCIFS：文件检索太慢而无法使用
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/10533653/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
JCIFS: file retrieval is too slow to be usable
提问by Xolve
I was just testing JCIFSfor accessing Windows shares. It is very slow to the point of being completely unusable.
我只是在测试JCIFS以访问 Windows 共享。它非常缓慢，以至于完全无法使用。
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());
}
}
}
It takes very long time for initial output to come and subsequent reads are also very slow. Any ideas how to use it? Any alternatives by which I can write Java code to access the Windows shares in a portable way are also welcome
初始输出需要很长时间，后续读取也很慢。任何想法如何使用它？也欢迎我可以编写 Java 代码以可移植方式访问 Windows 共享的任何替代方法
回答by Xolve
I found somewhere that SmbFileInputStream doesn't do its own buffering and hence the reason for being slow. Wrapping SmbFileInputStream in a BufferedInputStream solved the problem.
我在某处发现 SmbFileInputStream 不做自己的缓冲，因此是缓慢的原因。将 SmbFileInputStream 包装在 BufferedInputStream 中解决了这个问题。
SmbFile sFile = new SmbFile(path, authentication);
BufferedInputStream buf = new BufferedInputStream(new SmbFileInputStream(sFile));
回答by Glenn
In my own case, pushing files TO a Windows share via JCIFS was too slow to be usable.
在我自己的情况下，通过 JCIFS 将文件推送到 Windows 共享太慢而无法使用。
The solution turned out to be defining the property
解决方案原来是定义属性
-Djcifs.resolveOrder=DNS
The default inclusionof BCAST -- broadcasting a NetBIOS name query to 255.255.255.255 -- was needlessly resulting in a lengthy delay. (Link above de-framed from the top-level API docs.)
该默认包含广播NetBIOS名称查询到255.255.255.255 - - BCAST的是不必要导致长的延迟。（上面的链接来自顶级 API 文档。）
回答by floh.mueller
What I noticed is that jCIFS does "something" (afair jcifs.smb.SmbTransport.checkStatus(..))for every chunk it reads - i.e. for each chunk that is read into the buffer. That means using a BufferedInputStreammight really speed things up, but the real problem still exists. It only doesn't occur as often as before and therefore has a lower impact on the overall time ..
我注意到 jCIFS 做了“某事”（jcifs.smb.SmbTransport.checkStatus(..))对于它读取的每个块 - 即对于读入缓冲区的每个块。这意味着使用 aBufferedInputStream可能真的加快了速度，但真正的问题仍然存在。它只是没有t 像以前一样经常发生，因此对总时间的影响较小..
It helps a lot to set "jcifs.util.loglevel=3" and have a look what's really wrong!
设置“ jcifs.util.loglevel=3”很有帮助，看看到底哪里出了问题！
In my case I had to set "jcifs.smb.client.dfs.disabled=false"in the end, as "jcifs.resolveOrder=DNS"didn't help..
在我的情况下，我最终不得不设置"jcifs.smb.client.dfs.disabled=false"，因为"jcifs.resolveOrder=DNS"没有帮助..
回答by Stephen C
If you can rely on "something else" to mount the share as a local directory for you, then reading files in the mounted share in Java should be portable.
如果您可以依靠“其他东西”将共享挂载为本地目录，那么在 Java 中读取挂载共享中的文件应该是可移植的。
Even if this is not a real solution, it would be worth trying this to see if you get a faster read rate. A significantly faster read rate might change your mind about the relative importance of portability. And if you don't get a significant speedup, then you'll know that JCIFS is not to blame ...
即使这不是一个真正的解决方案，也值得尝试一下，看看是否可以获得更快的读取速度。明显更快的读取速度可能会改变您对便携性相对重要性的看法。如果你没有得到显着的加速，那么你就会知道 JCIFS 不是罪魁祸首......
回答by greatape
Even with the existing suggestions I still found JCIFS too slow to stream videos over my local network. It seems to be do with the overhead per buffer read from the network, even reading into large buffers JCIFS itself had a limited buffer size which was the problem.
即使有现有的建议，我仍然发现 JCIFS 太慢而无法通过本地网络流式传输视频。这似乎与从网络读取的每个缓冲区的开销有关，即使读取大缓冲区 JCIFS 本身也有一个有限的缓冲区大小，这就是问题所在。
If you look in https://jcifs.samba.org/src/patches/there's a patch, LargeReadWrite.patch. You'll need to apply the patch and rebuild the code to use it, but it made a big difference for me.
如果您查看https://jcifs.samba.org/src/patches/有一个补丁，LargeReadWrite.patch。您需要应用补丁并重新构建代码才能使用它，但这对我来说有很大的不同。
回答by I?igo Fabregas
The solution added by @Xolve0 worked for me as well. The buffer issue in the SmbFileInputis also present when trying to write files. I used the same BufferedInputStream(new SmbFileInputStream(sFile))to make the time execution decrease from 90secs to less than a second for a plain text file.
@Xolve0 添加的解决方案也对我有用。SmbFileInput尝试写入文件时也存在缓冲区问题。我使用相同的BufferedInputStream(new SmbFileInputStream(sFile))方法使纯文本文件的执行时间从 90 秒减少到不到一秒。
A quick way to identify this specific issue would be to track the time between the opening of the JCIFSpath and the write of the file itself.
识别此特定问题的一种快速方法是跟踪打开JCIFS路径和写入文件本身之间的时间。
回答by David Kleszyk
I know this is an old question, but for anyone else who has tried the other solutions to no avail:
我知道这是一个老问题，但对于尝试其他解决方案无济于事的其他人来说：
In my case, I was able to track the slowdown to jcifs' heavyuse of SecureRandom, which blocks if /dev/randomreports insufficient entropy.
就我而言，我能够跟踪 jcifs大量使用的减速SecureRandom，如果/dev/random报告熵不足，它会阻止。
Installing rng-toolsand configuring and enabling rngdbrought performance up to acceptable levels.
安装rng-tools、配置和启用rngd将性能提升到可接受的水平。
You can check the available entropy(on RHEL at least) with the following command:
您可以使用以下命令检查可用熵（至少在 RHEL 上）：
cat /proc/sys/kernel/random/entropy_avail
