Автор оригинала: Vlad Mihalcea.
Вступление
Поскольку настройка производительности очень важна, когда дело доходит до разработки уровня доступа к данным, в этой статье я покажу вам, как вы можете оптимизировать знаменитое приложение Hibernate Caveat Emptor с помощью оптимизатора гиперсуществования .
Приложение Caveat Emptor было создано Кристианом Бауэром и Гэвином Кингом для книги Hibernate в действии , опубликованной ими в 2004 году, и было включено как в первое, так и во второе издание хорошо известной Java Persistence с Hibernate книги.
Получение приложения с предупреждением
Вы можете получить все три версии приложения Caveat Emptor с веб-сайта Сохранение Java с гибернацией .
Для этой статьи я выбрал версию 2006 Caveat Emptor native Hibernate и хотел посмотреть, смогу ли я запустить Оптимизатор гиперсистенции для обнаружения проблем с производительностью.
Теперь, поскольку оптимизатору гиперсуществования требуется как минимум Hibernate 3.3, мне пришлось сделать несколько обновлений зависимостей, чтобы запустить свой тест:
hibernate3.jar⇢hibernate-core-3.3.0.GA.jarcommons-collections-2.1.1.jar⇢commons-collections-3.2.2.jartestng-5.4-jdk15.jar⇢testng-5.4-jdk15.jar⇢jboss-common.jar⇢slf4j-api-1.6.1.jar
И я добавил следующие зависимости:
И я добавил следующие зависимости:И я добавил следующие зависимости:
И, вот оно что!
Добавление теста настройки производительности приложения в режиме гибернации
Теперь, чтобы проанализировать проблемы с производительностью приложения Caveat Emptor, я создал следующий интеграционный тест:
public class PerformanceTuningTest
extends HibernateIntegrationTest {
protected void prepareSettings() {
dataSetLocation = "auction/test/basedata.xml";
beforeTestOperations.add(
DatabaseOperation.CLEAN_INSERT
);
}
@Test(groups = "integration-hibernate")
public void checkPerformanceIssues() {
List events = new HypersistenceOptimizer(
new HibernateConfig(
HibernateUtil.getSessionFactory()
)
).getEvents();
Assert.assertTrue(events.isEmpty());
}
}
И, запустив этот интеграционный тест, я получил следующий результат:
Hypersistence Optimizer - 47 issues were found: - 1 BLOCKER, - 31 CRITICAL, - 5 MAJOR, - 10 MINOR
Из всех этих проблем 40 связаны с картографированием:
- 12 Событие генератора идентификаторов
- 9 Событие Размера Столбца Целочисленной Версии
- 7 Событие Нетерпеливой Выборки
- 4 Событие двунаправленной Синхронизации
- 2 Однонаправленное однократное событие
- 2 Событие Сбора элементов
- 1 Событие списка коллекций элементов
- 1 Событие Типа Дискриминатора Строк
- 1 Событие Пакетной выборки
И 7 проблем, связанных с конфигурацией:
- 1 Событие DriverManagerConnectionPr ovider
- 1 Событие регистрации многострочного оператора
- 1 Событие регистрации Оператора комментария Sql
- 1 Событие Вставки Пакетного Заказа Jdbc
- 1 Событие Обновления Пакетного Заказа Jdbc
- 1 Событие Объектов С Пакетной Версией Jdbc
- 1 Событие Генерации схемы
Событие генератора идентификаторов
Событие Генератор идентификаторов сообщается следующим образом:
CRITICAL - IdentityGeneratorEvent - The [id] identifier attribute in the [ItemEntity] entity uses the [IdentityGenerator] strategy, which prevents Hibernate from enabling JDBC batch inserts. Consider using the SEQUENCE identifier strategy instead.
Если мы обратимся к Посреднику , мы увидим, что, действительно, я d отображается следующим образом:
Использование генератора IDENTITY не рекомендуется, если базовая база данных поддерживает последовательности, так как вы не сможете извлечь выгоду из автоматической пакетной вставки .
Нетерпеливое Событие Выборки
Событие Нетерпеливая выборка сообщается следующим образом:
CRITICAL - EagerFetchingEvent - The [deliveryAddress] attribute in the [Shipment] entity uses eager fetching. Consider using lazy fetching, which not only that is more efficient, but is way more flexible when it comes to fetching data.
Адрес доставки связь в Отправке сущности отображается следующим образом:
Поскольку атрибут fetch установлен в стратегию join , эта ассоциация будет извлекаться с нетерпением каждый раз в Отгрузка загружается, даже когда нам не нужна эта ассоциация.
Использование сопоставлений с быстрой выборкой не рекомендуется, поскольку это может привести к очень серьезным проблемам с производительностью. Мало того, что ассоциации будут извлечены, даже если они не нужны, но они также могут вызвать проблемы с запросами N+1.
Для получения более подробной информации об этой теме ознакомьтесь с этой статьей .
Событие двунаправленной Синхронизации
Событие Двунаправленной синхронизации сообщается следующим образом:
CRITICAL - BidirectionalSynchronizationEvent - The [categorizedItems] bidirectional association in the [Item] entity requires both ends to be synchronized. Consider adding the [addCategorizedItem(CategorizedItem categorizedItem)] and [removeCategorizedItem(CategorizedItem categorizedItem)] synchronization methods.
Действительно, если вы перейдете по элементу , вы увидите, что он не содержит методов addCategorizedItem и remove CategorizedItem .
Не рекомендуется синхронизировать обе стороны двунаправленной связи, так как режим гибернации не гарантирует, что переходы состояния сущности будут распространяться должным образом.
Для получения более подробной информации об этой теме ознакомьтесь с этой статьей .
Круто, правда?
Вывод
Оптимизатор персистентности Hy – очень универсальный инструмент. Мало того, что он работает с Spring Boot, Spring, Jakarta EE, Java EE, Play или другими фреймворками, но вы можете использовать его даже с устаревшими приложениями, использующими очень старые версии Hibernate.
Если вы хотите ускорить свой уровень доступа к данным, оптимизатор гиперсистенции, несомненно, поможет вам достичь вашей цели. И он не только обнаружит текущие проблемы, но и вы можете использовать его, чтобы предотвратить повторение этих проблем с помощью автоматического интеграционного теста, который проверяет, что проблема не обнаружена.