Обычный в спящем режиме ловушка производительности
У нас есть просто конец для профилирования нашего приложения. (она, начинают быть медленным). проблема, кажется, "в, в спящем режиме".
Это - отображение прежней версии. Кого работу, и делают это - задание. Реляционная схема позади в порядке также.
Но некоторый запрос является медленным как ад.
Так, мы ценили бы любой вход на общей и обычной ошибке, сделанной с, в спящем режиме, кто заканчивает с медленным ответом.
Exemple: Нетерпеливый вместо Ленивого может изменить поразительно время отклика....
Редактирование: Как обычно, читайте, руководство часто является хорошей идеей. Целая глава касается этого предмета здесь:
http://docs.jboss.org/hibernate/core/3.3/reference/en/html/performance.html
3 ответа
Одна из самых распространенных ошибок - это печально известная n + 1 выбирает задачу . По умолчанию Hibernate не загружает данные, которые вы не запрашивали. Это снижает потребление памяти, но создает проблему выбора n + 1, которой можно избежать, переключившись на правильную стратегию выборки, чтобы получить все данные, необходимые для загрузки объектов в их надлежащим образом инициализированном состоянии.
Но также не извлекайте слишком много, иначе вы столкнетесь с противоположной проблемой, декартовой проблемой продукта : вместо выполнения многих операторов SQL вы можете в конечном итоге создать операторы, которые извлекают слишком много данные.
В этом весь смысл настройки: найти середину между недостаточным и слишком большим объемом данных для каждого варианта использования вашего приложения (или, по крайней мере, для того, которое требует настройки).
Мои рекомендации:
- сначала активируйте ведение журнала SQL на уровне Hibernate
- запустите критические варианты использования (20% используются 80% времени) или даже все из них, если у вас есть такая роскошь
- выявить подозрительные запросы и оптимизируйте план выборки, проверьте, правильно ли используются индексы и т. д.
- задействуйте вашего администратора базы данных
Как ребята уже говорили, производительность Hibernate зависит от правильных настроек. Однажды я смог улучшить скорость обновления кэша некоторых мандатов в 10 раз (с 2 до 200 мс), переключившись на stateless session (этот конкретный код не зависел от какого-либо типа ленивой выборки, поэтому я мог спокойно делать то, что делал).
Вспоминается один случай, произошедший в моей компании. Вы могли бы посмотреть, загружает ли загрузка сущности также некоторую сериализованную сущность, которая будет десериализовываться каждый раз, когда загружается сущность. Кроме того, при фиксации транзакции hibernate может выполнить flush() для вас (настраивается). Если он выполняет flush, то для поддержания персистентности он выполнит сравнение зафиксированной сущности с той, что находится в базе данных. В этом случае он будет сравнивать сериализованный объект, что занимает много времени.
Еще одна вещь, которую вы можете сделать, это проверить, нет ли у вас ненужного каскадирования персистентности, т.е. @Cascade({CascadeType.PERSIST, CascadeType.SAVE_UPDATE}) аннотации на колонках.
Еще одна вещь, которая не конкретно связана с hibernate, заключается в том, что вы создаете представления для выполнения одного запроса, вместо того чтобы делать много-много запросов к разным таблицам. Для нас это имело огромное значение при работе над определенной функцией.