Музаффарникто не работает с ORM'ами? или никто не сталкивался с проблемой N+1?
Все спали ещё, до офисов не добрались. А что за срочность?

Музаффаробъясните пожалуйста в двух словах о проблеме N+1 и как решается такая задача?
Что такое ассоциации один ко многим и многие ко многим знаем?
Что такое ленивая (отложенная) загрузка знаем?

Проблема возникает когда ORM загружает коллекцию объектов. Но объекты внутри этой коллекции ленивые, некоторые данные не догружены. Но коду эти данные нужны и он перебирает коллекцию и читает объекты в цикле. В результате ORM догружает недостающие данные тоже в цикле, выполняя по одному запросу на каждый объект. Вот и получает 1 запрос чтобы вычитать коллекцию. + N запросов на каждый объект в коллекции.


МузаффарЗ.Ы. если я не ошибаюсь то решаются такие проблемы с использованием JOIN FETCH и т.д. но не совсем понимаю...
Не всегда именно JOIN, но да, решается указанием ORM что нужно догрузить недостающие данные сразу же (не лениться). А там уже в зависимости от обстановки либо один запрос с JOIN, либо несколько запросов, либо подзапросы. Не суть важно. Но число это ограничено количество ассоциаций, в то время как N - число объектов в коллекции, зачастую, на много больше.

Музаффарmad_nazgul, Blazkowicz,
дело в том что грузиться а когда добавил в persistence.xml профайлер (
) то получаю вот такую картину
Ладно. Держи нас в курсе.

Музаффарситуация с загруженности чуть улучшилась после применения fetch=FetchType.LAZY
но цифры до сих пор большие...
или ещё что то надо применить?
Проблема не решается конфигурацией маппинга. Для разных сценариев нужна выборка разных данных. Поэтому fetch нужно указывать в каждом конкретном запросе тем или иным образом.

Музаффарправильно ли я написал запрос?:

Запусти и посмотри.

Музаффари вроде для простого вывода достаточно будет вот такой запрос?:

Не знаю чем простой вывод отличается от сложного.

Музаффарили если самый последний чайлд, то?:

Поскрёбышь что ли?

Профайлер же четко показал что Users и Roles загружается по PK очень часто.
В связи с чем, надо найти все запросы, которые возвращают списки пользователей и ролей. Затем проверить что в них Users и Roles замаплены лениво. Затем добавить fetch в запросы, чтобы оптимизировать выборку этих сущностей внутри основного запроса.

Как именно добавлять fetch в запросы нужно смотреть в мануале ORM.

МузаффарBlazkowiczПрофайлер же четко показал что Users и Roles загружается по PK очень часто.
В связи с чем, надо найти все запросы, которые возвращают списки пользователей и ролей. Затем проверить что в них Users и Roles замаплены лениво. Затем добавить fetch в запросы, чтобы оптимизировать выборку этих сущностей внутри основного запроса.

Прошу прошения но можете поподробнее? что, где, как?
Что "что", что "где" и что "как"? Если научится формулировать свои вопросы, то шансы получить на них внятный вопрос вырастут в разы.

Музаффар,

Запускайте отдельные бизнес-транзакции по одной и смотрите что показывает профайлер. Заметили N+1, смотрите лог запросов, анализируйте свой код, чтобы понять почему это происходит.

Музаффарзаметил один странность... пока убрал в коммент все неиспользуемые запросы, смотрел в профайлер как бы снизился до 100, думаю что это хорошо но для проверки просто так обновил страничку (т.е. F5) смотрю в профайлер там уже не 100 а к примеру 120 при этом я ничего не поменял ни в базе ни в кода просто обновил страницу...
"запрос" это не обязательно JPQL запрос. Это может быть и загрузка объекта по PK, внутри которого коллекция ленивых сущностей. Это может быть и Criteria API запрос.