Стратегии оптимизации производительности унаследованного приложения EJB3

Во всех компонентах EJB все отношения определены с помощью стратегии выборки FetchType.EAGER. Объяснит ли это проблемы с производительностью операций чтения?

В зависимости от отношений между классами вы можете получить гораздо больше (всю базу данных?), чем на самом деле требуется при извлечении сущностей?

Целесообразно ли начинать настройку со стратегий выборки?

Я не могу сказать, что делать все отношения EAGER очень стандартным подходом. По моему опыту, вы обычно держите их ленивыми и используете "Fetch Joins" (тип соединения, позволяющий получить ассоциацию), когда вы хотите быстро загрузить ассоциацию для данного варианта использования.

Но это не объясняет проблемы с производительностью при операциях обновления, или нет?

Это могло бы. Я имею в виду, что если приложение извлекает граф больших толстых объектов при чтении, а затем отправляет тот же граф толстых объектов обратно, чтобы обновить только корневой объект, это может привести к снижению производительности. Но немного странно, что код использует em.persist(Object) для обновления сущностей.

Исходя из вашего опыта, каковы типичные и наиболее распространенные ошибки кодирования, которые приводят к проблемам с производительностью в операциях CRUD, с чего мне следует начать исследование/оптимизацию?

К очевидным относятся:

1. Получение большего количества данных, чем требуется
2. Проблемы с запросами N+1 (неверная стратегия выборки)
3. Плохо написанные запросы JPQL
4. Неподходящие стратегии наследования
5. Ненужные обращения к базе данных (например, отсутствие кэширования)

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

С позиции DBA.

Исходя из вашего опыта, каковы типичные и наиболее распространенные ошибки кодирования, которые приводят к проблемам с производительностью в операциях CRUD, с чего мне следует начать исследование/оптимизацию?

1. Отключить кеширование
2. Включить ведение журнала sql Ejb3/Hibernate по умолчанию генерирует множество крайне глупых запросов.
3. Теперь Вы видите, что я имею в виду.
4. Измените FetchType.EAGER на FetchType.LAZY.
5. Скажите «нет» большой бизнес-логике между em.find em.persist
6. Используйте ehcache http://ehcache.org/
7. Включить кеш сущностей
8. Если можете, сделайте первичные ключи неизменяемыми ( @Column(updatable = false, ...)
9. Включить кэш запросов

Никогда не используйте Hibernate, если вам нужна высокая производительность: http://www.google.com/search?q=hibernate+sucks

В моем случае аналогичная проблема с производительностью не зависела от стратегии выборки. Или, скажем, было невозможно изменить бизнес-логику в существующих стратегиях выборки. В моем случае решение заключалось в простом добавлении индексов. Когда ваша объектная модель JPA имеет много отношений (OneToOne, OneToMany,...), вы обычно будете использовать операторы JPQL с большим количеством соединений. Это может привести к сложным переводам SQL. Когда вы взглянете на модель данных (сгенерированную JPA), вы обнаружите, что ни для одной из строк вашей таблицы нет индексов. Например, если у вас есть объект Customer и Address с отношениями oneToOne, на первый взгляд все будет хорошо работать. Клиент и адрес имеют внешний ключ. Но если вы делаете такие выборки

Select c from Customer as c where c.address.zip='8888'

вы должны позаботиться о столбце таблицы «zip» в таблице ADDRESS. JPA не будет создавать для вас такой индекс во время развертывания. Так что в моем случае я смог повысить производительность базы данных, просто добавив индексы. Оператор SQL в вашей базе данных выглядит так:

 ALTER TABLE `mydatabase`.`ADDRESS` ADD INDEX `zip_index`(`IZIP`);

В вопросе и в других ответах я слышу много «может быть» и «может быть».

Сначала узнайте, что происходит. Если вы этого не сделали, мы все просто ковыряемся в темноте.

Я не эксперт по такого рода системам, но этот метод работает на любом языке и в любой операционной системе.

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