我们在项目开发中,经常会使用sftp链接方式对远程文件进行下载。一般是先判断远程服务器上是否有该文件,若有,则下载;若没有,则不做处理。
在一次项目开发中使用com.jcraft.jsch.ChannelSftp.ls(String path)方法判断文件是否存在,一开始项目正常运行,但是运行一段时间后ls()性能特别缓慢, 由此引发了对ls方法的研究。
经过问题排查后,发现ls()方法调用一次花费了40秒,之前每次都是零点几秒的。再次深入排查,发现随着时间增加,该目录下的文件会越来越多,但是文件也才一千多个,总占用空间400M,这点容量不应该这么慢才对。继续排查发现远程服务器是window系统,多次测试后发现ls方法在window系统下随着文件增多性能特别慢。
这是之前性能缓慢的代码,若ls(String path)下面有文件,会返回内容,若没有该文件,会抛出异常,所以需要用try…catch捕获异常。
/** * 判断目录下是否存在指定文件 * @param directory * @param fileName * @param sftp * @return */ public boolean sftpFilesExist(String directory, String fileName,ChannelSftp sftp){ boolean result = true; try { sftp.cd(directory); sftp.ls(fileName); //底层还是先ls目录下的文件,然后一个个去找的,效率受文件数量和文件大小影响 linux影响不太明显,window下差别会挺大,所以不要用ls方法 } catch (Exception e) { logger.info("sftp {}目录下不存在该文件{}",directory,fileName+e.getMessage()); logout();//关闭sftp链接方法 result = false; } return result; }
ChannelSftp.ls(String path)方法说明:
说明:
Ls与stat底层查找文件的方法相同,都是调用SftpATTRS getATTR(Buffer buf)方法返回文件信息。不同的是由于ls()方法是循环扫描目录下的所有文件,直到找到文件为止,
所以ls()比stat()花费时间更长,ls()受文件总数的影响。另文件的大小会占用空间大小,导致ls()运行缓慢,所以ls()也受文件大小影响。
Ls()与stat()在window系统与linux系统下效率的对比:(下列数据均为平均值)
系统 | 数据类型 | Ls方法耗时(秒) | stat方法耗时(秒) |
---|---|---|---|
Windows | 1200个文件, 总量402M | 41 | 0.3 |
Windows | 2400个空文件 | 86 | 0.3 |
Windows | 2400个文件,总量824M | 128 | 0.3 |
Linux | 1200个文件,总量16G | 6 | 0.27 |
数据对比结论:
ls方法在windows系统下效率低下,并且受文件大小和文件数量的影响。
Ls方法在linux下效率较高,虽然也受文件大小和文件数量的影响,但是耗时相对较少。
Stat方法在windows与linux上效率比较稳定,且耗时少。
下面为修改后代码,无论window下还是linux下,stat()方法的效率都会比ls()方法效率高。
/** * 判断目录下是否存在指定文件 * @param directory * @param fileName * @param sftp * @return */ public boolean sftpFilesExist(String directory, String fileName,ChannelSftp sftp){ boolean result = true; try { sftp.cd(directory); // sftp.ls(fileName); 底层还是先ls目录下的文件,然后一个个去找的,效率受文件数量和文件大小影响 linux影响不太明显,window下差别会挺大 sftp.stat(fileName); //返回文件信息 -rwxrwxrwx 0 0 182000000 Wed Sep 23 14:44:49 CST 2020 } catch (Exception e) { logger.info("sftp {}目录下不存在该文件{}",directory,fileName+e.getMessage()); logout();//关闭sftp链接方法 retult = false; } return result; }