2009-04-24 2 views
5

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

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

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

ответ

3

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

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

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

У меня нет настройки производительности в конфигурации БД. Я предположил, что моя проблема, скорее всего, будет плохо продуманными запросами или слишком часто задавать неправильный вопрос. Наверное, я хотел бы сначала найти способ уменьшить количество запросов и их расход, а затем (после сокращения использования на 80%) ускорить сам db, используя кеширование и другие трюки на этой уменьшенной нагрузке. Но я не эксперт в настройке использования БД. Вы предлагаете настроить БД перед приложением? – PanCrit

+0

Если вы уверены, что проблема в спящем режиме, настройка DB не поможет. Перед настройкой используйте инструмент профилирования или что-то, что поможет вам точно отслеживать корень ваших проблем с производительностью, а затем оптимизировать его. К сожалению, нет простого способа. Хорошей новостью является то, что все IDE сегодня имеют достойную поддержку профилирования. – razenha

0

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

+0

Я не думаю, что это так огромно по сравнению с тем, что может сделать hsqldb. Файл .script длиной почти 300K (32891015 символов). Я смотрел ранее, и в БД хранится 3000 рынков и 150 тыс. Сделок. Может быть 250K строк общей по всем объектам. – PanCrit

0

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

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

0

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

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

VisualVMBTrace или встроенный в следовых) утверждает, что помочь с отслеживанием, но я не смог найти какой-либо инструмент, который показывает временные на вызовы методов.

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

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

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

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

+0

Вашkit полезен и прост в использовании. – PanCrit

0

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

Терракота с открытым кодом. Более подробную информацию можно скачать по адресу Terracotta for Hibernate.

Смежные вопросы