1

I' dooing pretty simple query

SELECT cmis:objectId, cmis:name, cmis:parentId
FROM cmis:folder
ORDER BY cmis:name

Running this query with apache cmis workbench take ~ 15 sec Running the same query with opencmis, is pretty quick, but going throught the result is terribly slow ~ 3 min.

session.query( queryStmt, false).iterator().toList()

By spliting the calls like this

def rs = session.query( queryStmt, false)
def iterator = rs.iterator()
def folders = iterator.toList()

I was able to determine that the toList() is where it's slow. But i don't get why.

I also tried to define a operationContext and use it with the query. Same results. Here my operationContext

def filter = "cmis:objectId,cmis:name,cmis:parentId"
def context = session.createOperationContext()
context.setCacheEnabled(false)
context.setFilterString(filter)
context.setRenditionFilterString(filter)

Any idea on how to perform this query faster ?

benzen
  • 6,204
  • 4
  • 25
  • 37

2 Answers2

3

The CMIS Workbench only fetches the first 100 hits by default. Depending on the repository, that's usually fast. Increase "max hits" to get more.

To replicate what the CMIS Workbench is doing, try this code snippet:

String queryStmt = "SELECT cmis:objectId, cmis:name, cmis:parentId FROM cmis:folder ORDER BY cmis:name";
int maxHits = 100;

OperationContext context = session.createOperationContext();
context.setMaxItemsPerPage(maxHits);

session.query(queryStmt, false, context).getPage(maxHits).iterator().toList();

toList iterates over all results of the query. The default OperationContext defines batches of 100 hits. That is, under the hood OpenCMIS will do several (possibly many) query calls to the repository, asking for the first 100 hits, the second 100 hits, the third 100 hits, ...

If you have a million hits in total, you end up with quite a few back-end calls.

Try increasing the batch size with context.setMaxItemsPerPage(1000000). This is usually faster if you have many hits and want them all as a list.

Small batches are better when you consume them in a loop and don't need them all at once. It also allows handling of result sets that don't fit into the clients memory.

And another aspect: Get rid of the ORDER BY and sort the list later in Java. You have the result set in memory anyway. If the repository has no index on cmis:name, it can slow down the query processing on the server side.

Florian Müller
  • 3,215
  • 1
  • 14
  • 11
  • Thanks for you answer. What you explain make a lot of sense. I've tryed it. Yet i experience the slow response time. Now i don't know if my alfresco is less loaded and can response a bit quicker. My java query now take 1min. But it's still 5 times more slow than the cmis workbench – benzen Apr 20 '17 at 13:44
  • In my humble opinion here is the call from workbench gui to opencmis client api: https://github.com/apache/chemistry-opencmis/blob/trunk/chemistry-opencmis-workbench/chemistry-opencmis-workbench/src/main/java/org/apache/chemistry/opencmis/workbench/model/ClientModel.java#L279-L285 Looking at this there is quite a few config in addition to what @florrian müller proposed. I've copied this, and now my query run 4 time faster than before. I'm in the process of removing config in the operationContext to find out what is important – benzen Apr 20 '17 at 14:31
0

Thanks @Florian for your help.

He is what solved my problem.

def context = session.createOperationContext()
context.includeAllowableActions = false
context.maxItemsPerPage = 15000
def folderList = session.query(getFoldersList, false, context).iterator().toList()

Of course in real life, the max number of items by page should not be an arbitrary number like this.

Community
  • 1
  • 1
benzen
  • 6,204
  • 4
  • 25
  • 37