Оптимизация стропа запросы

Question

У меня есть компонент cq5, который должен запросить данный путь для пары других типов компонентов, как это:

String query = "select * from nt:unstructured where jcr:path like '/content/some/path/%' and (contains(sling:resourceType, 'resourceType1') or contains(sling:resourceType, 'resourceType2')) "; 
    Iterator<Resource> resources = resourceResolver.findResources(query,"sql"); 

К сожалению, если он работает по пути с большим количеством контента страницы, время вышло. Есть ли способ оптимизировать такую ​​функцию или советы по повышению производительности?

Answer 1

1. Используйте более конкретный тип JCR, чем nt:unstructured.

Я думаю, вы ищете узлы страницы, поэтому попробуйте cq:Page или (еще лучше) cq:PageContent.

2. Денормализовать ваши данные.

Если я правильно понимаю ваш запрос, он должен возвращать страницы, содержащие resource1 или resource2. Вместо использования предиката , что очень дорого и не позволяет JCR использовать индекс, помечать страницы, содержащие эти ресурсы, дополнительным атрибутом. . Например, установите jcr:content/containsResource1 и jcr:content/containsResource2 свойства соответствующих, а затем использовать их в запросе:

select * from cq:PageContent where (containsResource1 is not null or containsResource2 is not null) and jcr:path like '/content/some/path/%' 

Вы можете использовать EventHandler или SlingPostProcessor автоматически устанавливать свойства при resource1 или resource2 добавляется.

Answer 2

Я добавил теги «jackrabbit» и «jcr» к вашему вопросу. Я не эксперт в JCR-запросах, но один из этих экспертов может захотеть прокомментировать используемую вами инструкцию запроса и если и как могут быть оптимизированы.

Это утверждение говорит о том, что это означает, что клиентский браузер отключен, так как он слишком долго не получает данные. Сначала я должен проверить (с помощью отладчика или операторов журнала), если это действительно вызов findResources, который занимает слишком много времени, или если это код, который запускается после этого, является виновником.

Если findResources работает медленно, вам нужно будет оптимизировать запрос или перепроектировать ваш код, чтобы сделать его асинхронным, например, чтобы клиентский код сначала получил HTML-страницу, а затем получил результаты запроса через асинхронные вызовы.

Если код, который запускается после того, как findResources вызывает таймаут, вы можете переконфигурировать его, чтобы как можно скорее отправить данные в браузер и регулярно очищать выходные данные, чтобы избежать тайм-аутов. Но если вы найдете много результатов, которые могут потребоваться слишком долго для пользователя в любом случае, и тогда потребуется более асинхронное поведение.