We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
不得不说,这个问题还是比较严重的,基本上数量稍微破千,就有明显的页面响应缓慢了。建议:
FolderViewServiceImpl.java的实现,可以考虑基于数据库进行操作,即refresh的时候,把所有文件及文件夹的id、层数、全部路径等都写入数据库,然后之后的操作都从数据库进行索引。
FolderViewServiceImpl.java中可以考虑用多线程实现并行处理,经过测试,发现FolderMapper接口的countByParentID方法,与FolderUtil接口的getParentList非常耗时。查询当前文件夹的父级文件夹和子文件夹,就可以并行操作。
The text was updated successfully, but these errors were encountered:
您好,这一问题已经收到。相关的优化建议已经记录并将作为未来升级的参考方案——性能优化一直是kiftd关注的重点之一。
Sorry, something went wrong.
在Windows系统中,有个快速提升速度的办法就是,将存放文件的那个文件夹,加入windows的索引index中, 我的服务器文件夹有4-5万个子文件夹, 以前进入文件夹都要显示半天, 自从加了索引后, 提升速度非常明显。
@hks2002 非常感谢您提供的建议!但遗憾的是,这一方法可能无法提高kiftd的响应速度。由于kiftd的文件管理基于的是自身数据库,而非直接遍历操作系统的文件系统,因此,操作系统的遍历文件速度对于kiftd遍历文件的速度影响不大,真正起到决定性影响的实际上是kiftd内置的H2 DB的遍历速度。当然,未来进一步提升大数目文件的处理速度的方法还将作为主要研究方向进行研究。
No branches or pull requests
不得不说,这个问题还是比较严重的,基本上数量稍微破千,就有明显的页面响应缓慢了。建议:
FolderViewServiceImpl.java的实现,可以考虑基于数据库进行操作,即refresh的时候,把所有文件及文件夹的id、层数、全部路径等都写入数据库,然后之后的操作都从数据库进行索引。
FolderViewServiceImpl.java中可以考虑用多线程实现并行处理,经过测试,发现FolderMapper接口的countByParentID方法,与FolderUtil接口的getParentList非常耗时。查询当前文件夹的父级文件夹和子文件夹,就可以并行操作。
The text was updated successfully, but these errors were encountered: