Для Lazy Load или нет для улучшения производительности

Question

Было высказано предположение, что для повышения производительности нашей системы следует использовать ленивую загрузку по всем направлениям. То есть изменить отображение OneToOne со свойством «mappedBy» на отображение @OneToMany. Это необходимо для устранения и остановки загрузки нежелательных данных из базы данных, что приводит к замедлению работы приложений.

Мы используем многоуровневую систему (в основном, 2 уровня). У нас есть внешний интерфейс - использующий JSF и внутренний, который содержит уровни доступа к бизнесу и базе данных. Передняя и задняя сторона отображают представление EJB - но в EJB нет реальной логики. Другие используемые технологии - Spring и Hibernate

Теперь, после некоторого прочтения этой темы, кажется, что использование отложенной загрузки не является «серебряной пулей» в том смысле, что ее нужно применять правильно. Для каждой отложенной загрузки выдается оператор Select для извлечения данных. Существует также проблема, заключающаяся в том, что, если внешний интерфейс делает доступ к свойству, которое должно быть отложено, и сеанс / соединение закрывается на внутреннем конце, то мы получим нулевое значение.

Является ли вышеприведенное правильным вопросом?

Итак, каков наилучший подход / практика для реализации решения для отложенной загрузки или улучшения производительности? Надежда не переделывать модель данных, если это вообще возможно.

Сначала я работал с группой администраторов баз данных, чтобы получить представление о том, что происходит между двумя системами - как выглядят запросы, как мы используем данные и т. Д. Определите проблемные места, изучите объект / запросы Hibernate. чтобы увидеть, как лучше его улучшить. Также посмотрите на внешний интерфейс, чтобы определить, что и как данные передаются от задней части к передней для отображения и т. Д.

Хороший подход / другие подходы?

Answer 1

Самое первое, что вы должны сделать, это измерить ваше приложение и выяснить, что именно вызывает ваши проблемы с производительностью.

Используйте такой инструмент, как JProfiler, чтобы выяснить, где проблемы.

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

Просто перейти к реализации ленивой схемы загрузки, не зная, что вызывает проблемы с производительностью, будет пустой тратой времени.

Если вы обнаружите, что проблема заключается в уровне БД, тогда вы можете привлечь БД, чтобы посмотреть, можно ли улучшить вашу схему / запросы, прежде чем делать что-то более радикальное.

Answer 2

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

То, как я реализовал ленивую загрузку, не изменило уровень данных. Все это было связано с бизнес-логикой и контроллерами представления. Поскольку я не знаком с EJB, я собираюсь предположить, что это будет работать для вашего Java-приложения. В любом случае, когда я реализую ленивую загрузку, я не загружаю никаких данных (по крайней мере, ни одну из данных, которые я собираюсь загрузить лениво), пока это не понадобится. Затем я вызываю уровень данных и получаю свои данные (или подмножество данных).

Что касается проблемы с соединением, вам нужно будет поставить чеки на место, чтобы проверить соединение для передачи данных и проверить, закрыто ли оно. То есть вы объединяете соединения для передачи данных. Затем, если соединение закрыто, снова откройте его. Но, как и в случае с реализацией отложенной загрузки, это следует делать в ваших классах логики, а не во внешнем интерфейсе, поэтому вам не придется дублировать эту функцию много раз.

Answer 3

От того, что ты пытаешься сделать, зависит так много, что трудно сказать. Ваша идея пойти в свой DBA может быть продуктивной, безусловно. Единственное, что люди могли бы сделать, это привести несколько примеров. В моем случае:

Ленивая загрузка стала для нас огромным улучшением производительности в следующем сценарии. У нас было огромное дерево с 15 000 узлов с разными уровнями. Первоначально мы пытались загрузить все дерево, а затем отрендерить его. Это заняло целую вечность. Мы изменили код, чтобы лениво загружать ветки только тогда, когда пользователь расширил узлы. Расширение узла занимает немного больше времени, но в целом приложение работает быстрее. В этом случае имеет смысл изменить отображение

Теперь, если вам все равно нужно обработать все дерево, поскольку это требуется вашей бизнес-логикой, ленивая загрузка не будет иметь большого значения. В этом случае простое изменение сопоставления на самом деле не является решением, а может быть даже дороже.

Вам нужно немного подумать о том, что делает ваше приложение, о том, где оно ощущается медленно, о том, что вы пытаетесь выполнить. Вытащить профилировщик тоже не серебряная пуля.

Без конкретных примеров из вашего приложения нет смысла говорить, полезна ли отложенная загрузка.

Answer 4

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

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