Liferay 并发文件条目上传



问题陈述:

在Liferay中,我必须将zip文件导入到liferay cms中的某个文件夹中,到目前为止,我已经实现了zip文件的串行解压缩,创建了它的文件夹,然后是文件。这里的问题是整个过程需要很多时间。所以我不得不使用并行方法来创建文件夹和创建文件。

我的解决方案 :

我使用javajava.util.concurrent.ExecutorService创建了一个Executors.newFixedThreadPool(NTHREDS),其中NTHREDS是并行运行的线程数(例如5个)

  1. 我从zip中读取了所有文件夹路径并放置了zip列表 针对文件夹路径作为哈希映射中的键的整个(文件)
  2. 遍历映射中的所有键并串行创建文件夹
  3. 现在从map遍历zip条目(文件)列表并传递给线程工作线程,每个工作线程一个文件,然后将这些工作线程发送到 执行器服务执行

到目前为止,我没有发现整个过程的时间有任何显着减少,我是否朝着正确的方向前进?Liferay是否支持并发文件添加?我做错了什么?

我将非常感谢在这方面的任何帮助

下面是我的代码

imports 
...
...
public class TestImportZip {
private static final int NTHREDS = 5;
ExecutorService executor = null;
...
...
....
Map<String,Folder> folders = new HashMap<String,Folder>();
File zipsFile = null;
public TestImportZip(............,File zipFile, .){
.
.
this.zipsFile = zipFile;
this.executor = Executors.newFixedThreadPool(NTHREDS);
}
// From here the process starts
public void importZip() {
Map<String,List<ZipEntry>> foldersMap = new HashMap<String, List<ZipEntry>>();
try (ZipFile zipFile = new ZipFile(zipsFile)) {
zipFile.stream().forEach(entry -> {
String entryName = entry.getName();
if(entryName.contains("/")) {
String key = entryName.substring(0, entryName.lastIndexOf("/"));
List<ZipEntry> zipEntries = foldersMap.get(key);
if(zipEntries == null){
zipEntries = new ArrayList<>();
}
zipEntries.add(entry);
foldersMap.put(key,zipEntries);
}
});
createFolders(foldersMap.keySet());
createFiles(foldersMap);
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
private void createFolders(Set<String> folderPathSets) {
// create folder and put the folder in map
.
.
.
folders.put(folderPath,folder); 
}
private void createFiles(Map<String, List<ZipEntry>> foldersMap) {
.
.
. 
//Traverse all the files from all the list in map and send them to worker
createFileWorker(folderPath,zipEntry);
}
private void createFileWorker(String folderPath,ZipEntry zipEntry) {
CreateEntriesWorker cfw = new CreateEntriesWorker(folderPath, zipEntry);
executor.execute(cfw);
}
class CreateEntriesWorker implements  Runnable{
Folder folder = null;
ZipEntry entryToCreate = null;

public CreateEntriesWorker(String folderPath, ZipEntry zipEntry){
this.entryToCreate = zipEntry;
// get folder from already created folder map
this.folder = folders.get(folderPath);
}
public void run() {
if(this.folder != null) {
long startTime = System.currentTimeMillis();
try (ZipFile zipFile = new ZipFile(zipsFile)) {
InputStream inputStream = zipFile.getInputStream(entryToCreate);
try{
String name = entryToCreate.getName();
// created file entry here 
}catch(Exception e){
}finally{
if(inputStream != null)
inputStream.close();
}
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
}
}

您的简化代码不包含我认识的任何Liferay参考。您提供的描述提示您正在尝试优化某些代码,但无法从您的尝试中获得更好的性能。这通常表明您正在尝试优化问题的错误方面(或者已经完全优化)。

您需要确定操作的实际瓶颈,以便了解优化是否可行。俗话说"过早优化是万恶之源"。什么意思?

我将在这里完全编造数字 - 不要引用我的话:它们是为了说明目的而自由发明的。假设您将Zip文件的内容添加到Liferay存储库的操作被分发到以下百分比的操作资源:

  • 4% zip 文件解码/解压缩
  • 6% 用于 zip 操作和临时文件的文件 I/O
  • 用于存储文件的 10% 数据库操作
  • 60% 用于从存储在 zip 文件中的 Word、PDF、Excel 和其他文件中提取纯文本,以便在全文索引中索引文档
  • 全文索引库的 20% 开销,用于将索引放在一起。

假设您正在优化 zip 文件解码/解压缩 - 您可以期待数字的整体改进?

虽然我的数字是编造的:如果你的优化没有任何结果,我建议反转它们,衡量你需要优化的地方,然后去那个地方(或者接受它,如果那个地方遥不可及,就升级你的硬件)。

针对 CPU、I/O、内存和其他潜在瓶颈运行这些数字。确定您的实际瓶颈#1,修复它,再次测量。你会看到瓶颈#2得到了提升。重复冲洗,直到您满意为止

最新更新