Сколько накладных расходов приносят фреймворки, такие как Hibernate?

Question

Разработчики иногда забивают многоуровневые корпоративные веб-приложения ... «Предприятие» рассматривается некоторыми как синоним медленного, раздутого и ресурсоемкого.

Оказывают ли такие структуры, как Hibernate, нетривиальное влияние на производительность по сравнению с написанием собственных DAO или других менее абстрактных подходов? Я предполагаю, что нетривиальным является вопрос: «Заметно ли, что пользователь замечает, что страницы загружаются медленнее»?

Answer 1

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

PS Не забудьте использовать надлежащие инструменты с Hibernate, такие как Hibernate profiler . Они могут творить чудеса!

PPS Использование Hibernate не заменяет знание вашего SQL!

Answer 2

Нетривиально, я полагаю, что вопрос заключается в том, «в результате чего пользовательские страницы загружаются медленнее».

Для большинства приложений CRUD на самом деле все наоборот. При правильном использовании и настройке Hibernate будет генерировать более качественный SQL, чем большинство разработчиков (извините, но это правда), а также такие функции, как отложенная загрузка, кэширование первого уровня (кэш уровня транзакций), кэширование второго уровня (кэш глобального уровня), запрос кэширование сделает его лучше, чем подходы более низкого уровня (пользовательские SQL и DAO).

И поскольку кто-то упоминал о пакетных обновлениях и больших наборах результатов, я бы подчеркнул, что в Hibernate есть StatelessSession для этих вариантов использования. Но я не думаю, что они входят в сферу интерактивной части веб-приложения (если ваш поиск извлекает 10app записей в веб-приложении, вы делаете это неправильно).

Answer 3

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

Не уверен, если вы спросите об этом, потому что есть требование к приложению, которое говорит, что производительность важна, или вы просто задаетесь вопросом, но учтите это: были некоторые люди, которые использовали Hibernate в приложении и заметили, что это было sloooow. Затем некоторые ребята реорганизовали его, оптимизировали с помощью простого JDBC, iBatis или чего-то еще, и он запустил faaaaast. Итак, вывод был: Hibernate медленный.

Но они не считали, что технология была использована не по назначению. Да ... круто, что вы можете написать object.getX().getZ().getW().getSomeOtherThing().getEtc(), и это просто работает, но Hibernate сгенерирует SQL, и Небеса вам в этом помогут.

Прежде чем что-либо делать, рассмотрим правила оптимизации:

• Первое правило оптимизации - не делай Это.
• Второе правило оптимизации (для экспертов) - не делайте этого ... пока.

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

Answer 4

Это во многом зависит от того, что вы делаете. Обычно ваши пользователи не заметят различий во внешнем интерфейсе, но есть несколько моментов, на которые следует обратить внимание:

• ORM мапперы не очень хороши в пакетном обновлении или обработке больших наборов результатов.

• Если у вас сложный набор отношений, ваш ORM mapper может замедлить процесс, потому что он соединяется «неправильным» образом. Или получает слишком много данных.

• Если ваш сайт действительно сильно загружен, дополнительные циклы ЦП могут помешать, но это маловероятно.

ORM mapper может значительно упростить разработку вашего программного обеспечения. Следите за производительностью и выполняйте 1% всего в прямом SQL, но сохраняйте Hibernate в остальных 99%.