Переход на уровень БД идет слишком глубоко. Вышеуказанный запрос заключается в том, чтобы запрос JCR о получении всех свойств узла с идентификатором, равным NODE_ID, но, как вы говорите, бессмысленно с точки зрения сообщать, где / какая операция его вызывает.
Может быть любым из:
ctx.getJCRSession('some_workspace').getNode('some_path')
до:
node.getNode('some_subpath')
до:
searchfn.searchPages('...')
или даже:
cmsfn.children(node)
и, возможно, еще немного.
Чтобы еще больше усложнить ситуацию, вы увидите запрос к БД, только если локальный (в памяти) кэш jcr не содержит элемент, запрошенный вашим шаблоном, так что вы даже не будете надежно перехватывать все запросы контента на уровне БД.
Одно можно сказать наверняка: запрос 1k + узлов для рендеринга одного шаблона в большинстве случаев указывает на то, что вы делаете что-то не так (если вы действительно не хотите рендерить что-то вроде резюме или обзор, охватывающий тысячи узлов).
Самый простой путь вперед - перестать думать о logi c в вашем шаблоне. Если он содержит несколько компонентов, вы пытаетесь прибить его к данному компоненту, чтобы ограничить пространство поиска, например, удаляя компоненты один за другим и наблюдая за изменениями.
Если это сводится к выполнению какого-либо запроса JCR, Вы можете настроить ведение журнала уровня отладки напрямую:
info.magnolia.templating.functions.SearchTemplatingFunctions
Это предполагает, что вы использовали searchfn для поиска по шаблону. В других случаях отладка будет немного сложнее, так как обычный JCR Node API используется для получения также всего другого содержимого (например, связанного с конфигурацией), а не только того, которое отображается на странице.
Вероятно, это одиночная команда или l oop в вашем шаблоне, что приводит к тому, что синхронизация выполнения различных частей шаблона также может дать вам подсказку и помочь сузить проблему. Если вы поделитесь самим шаблоном, возможно (но не гарантировано), что мы сможем найти в нем что-то и дать вам более точные индикаторы.