Как настроить производительность приложения hsqldb / hibernate

Question

У меня есть Java-приложение с открытым исходным кодом, которое использует Hibernate и HSQLDB для сохранения. Во всех моих игрушечных тестах дела идут быстро и все хорошо. У меня есть клиент, который непрерывно работает с программным обеспечением в течение нескольких месяцев, и его база данных значительно выросла за это время, а производительность постепенно снизилась. В конце концов мне пришло в голову, что база данных может быть проблемой. Насколько я могу судить по операторам журнала, все вычисления на сервере происходят быстро, поэтому это согласуется с гипотезой о том, что БД может быть виновата.

Я знаю, как выполнить обычное профилирование программы, чтобы выяснить, где находятся горячие точки и что занимает значительное количество времени. Но все известные мне профилировщики отслеживают время выполнения в программе и не помогают вам при обращении к внешним ресурсам. Какие инструменты люди используют для профилирования программ, использующих внешние вызовы БД, чтобы выяснить, где оптимизировать производительность?

Небольшой слепой поиск вокруг уже нашел несколько горячих точек - я заметил вызов, где я перечислял все объекты определенного класса, чтобы выяснить, были ли они. Изменение в одну строку критерия [.setMaxResults (1)] изменило этот вызов с полсекунды на практически мгновенный. Я также вижу места, где я задаю один и тот же вопрос из БД много раз за одну транзакцию. Я еще не понял, как кешировать ответ, но мне действительно нужен инструмент, который поможет мне более систематически искать подобные вещи.

Answer 1

К сожалению, насколько я знаю, для этого нет инструмента.

Но есть некоторые вещи, которые вы можете проверить:

• Используете ли вы нетерпеливую загрузку вместо отложенной загрузки? Судя по описанию вашей проблемы, похоже, что вы не используете ленивую загрузку ...
• Включили ли вы и правильно ли настроили кэширование второго уровня? Включая кеш запросов? Механизм кэширования в спящем режиме чрезвычайно мощный и гибкий.
• Рассматривали ли вы использование Hibernate Search? В зависимости от вашего запроса, полнотекстовый индекс Hibernate Search в верхней части Apache Lucene может ускорить ваши запросы (поскольку система индексирования настолько мощная)

Answer 2

В Terracotta 3.1 вы можете отслеживать всю эту статистику в режиме реального времени, используя Terracotta Developer Console. Вы можете просматривать исторические графики для статистики кэша, а также статистику спящего режима или статистику кэша для всего кластера или для каждого узла.

Терракота с открытым исходным кодом. Более подробная информация и загрузка в Терракотовая для Hibernate .

Answer 3

Много отчетов здесь. У меня есть некоторые результаты, и я все еще ищу хорошие ответы.

Я нашел несколько инструментов, которые помогают:

VisualVM (с BTrace или встроенной трассировкой) претендует на помощь в трассировке, но мне не удалось найти какой-либо инструмент, который показывает синхронизацию при вызовах методов.

YourKit считается полезным; Я попросил лицензию с открытым исходным кодом.

Самая полезная вещь, которую я нашел, - встроенная статистика Hibernate. Если вы установите hibernate.generate_statistics true в ваших свойствах вы можете отправить sessionFactory.getStatistics() и просмотреть подробную статистику о том, какие объекты были сохранены и извлечены и что влияет на кэши. Я нашел один из ответов, которые мне нужны, в qeuryStatistics, который сообщает для каждого скомпилированного запроса, попадания и пропадания кэша, количество выполнений запроса, сколько строк было возвращено, а также среднее, максимальное и минимальное время выполнения. Эти сроки ясно показали, куда идет время.

Затем я немного прочитал о кешировании. Предложение Разенхи было правильным. [Сейчас я отмечу его ответ как правильный.] Я добавил hibernate.cache.use_query_cache true в мои свойства и добавил query.setCacheable(true); к большинству моих запросов. Я также добавил <cache usage="read-write"/> к нескольким моим файлам .hbm.xml. Сейчас большая часть моей статистики показывает преобладание обращений к кешу, а производительность значительно выше.

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

Answer 4

Когда-то был инструмент под названием IronGrid / IronEye / IronTrackSql, который сделал именно то, что вы ищете. К сожалению, они ушли из бизнеса. Они открыли исходный код своего продукта в последнюю минуту, но я не мог найти источник или двоичный файл в течение достаточно долгого времени.

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

Answer 5

Сколько данных вы храните в HSQLDB? Я не думаю, что он хорошо работает при управлении большими наборами данных, так как он просто хранит все в файлах ...