Запрос OpenCmis медленнее, чем Apache cmis Workbench

Question

Я делаю довольно простой запрос

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

Выполнение этого запроса с помощью Apache cmis Workbench занимает ~ 15 секунд. Выполнение этого же запроса с opencmis довольно быстро, но получение результата очень медленное ~ 3 минуты.

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

Разделив звонки вот так

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

Я смог определить, что toList() это где медленно. Но я не понимаю почему.

Я также попытался определить OperationContext и использовать его с запросом. Те же результаты. Вот моя операция контекста

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

Любая идея о том, как выполнить этот запрос быстрее?

Answer 1

CMIS Workbench по умолчанию выбирает только первые 100 обращений. В зависимости от хранилища, это обычно быстро. Увеличьте "максимальное количество ударов", чтобы получить больше.

Чтобы повторить то, что делает CMIS Workbench, попробуйте следующий фрагмент кода:

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 перебирает все результаты запроса. По умолчанию OperationContext определяет пакеты по 100 обращений. Таким образом, под капотом OpenCMIS будет делать несколько (возможно, много) запросов запросов к хранилищу, запрашивая первые 100 обращений, вторые 100 обращений, третьи 100 обращений,...

Если у вас в общей сложности миллион обращений, вы в конечном итоге получите несколько внутренних вызовов.

Попробуйте увеличить размер партии с context.setMaxItemsPerPage(1000000), Это обычно быстрее, если у вас много хитов и вы хотите, чтобы они были представлены в виде списка.

Маленькие партии лучше, когда вы потребляете их в цикле и не нуждаетесь в них сразу. Это также позволяет обрабатывать наборы результатов, которые не помещаются в память клиентов.

И еще один аспект: избавиться от ORDER BY и сортировать список позже в Java. В любом случае, у вас есть результат в памяти. Если репозиторий не имеет индекса на cmis:name, это может замедлить обработку запросов на стороне сервера.

Answer 2

Спасибо Florian Müller за вашу помощь.

Именно он решил мою проблему.

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

Конечно, в реальной жизни максимальное количество элементов на странице не должно быть произвольным числом, подобным этому.