Блог

У меня есть отчет BIRT с проблемами производительности: его выполнение занимает примерно 5 минут.

Вначале я думал, что проблема заключалась в базе данных: в этом отчете используется довольно сложная хранимая процедура SQL Server для извлечения данных. После множества оптимизаций SQL выполнение этой процедуры теперь занимает ~ 20 секунд (в консоли управления).

Однако сам отчет по-прежнему занимает слишком много времени (несколько минут). Как мне определить другие узкие места при создании отчета BIRT? Есть ли способ профилировать весь процесс? Я запускаю его с помощью средства просмотра www (запущенного внутри Tomcat 5.5), и у меня нет никаких обработчиков событий Java, все выполняется с использованием стандартных SQL и JavaScript.

Я посмотрел вебинар «Разработка высокопроизводительных BIRT-отчетов» 1, в нем есть несколько интересных соображений, но это не сильно помогло…

На момент написания этого ответа вопросу уже почти 2 года, так что, предположительно, вы нашли способ обойти проблему. Никто не предлагал профилировщик для всего процесса, поэтому вот несколько способов определения бутылочных горлышек.

1. Время запуска — здесь можно потратить около минуты

   • запуск пары отчетов один за другим или второго после запуска первого может помочь в диагностике проблем.

2. Время выполнения SQL-запроса — В вопросе упоминаются хорошие решения

   • любая трассировка SQL и тестирование производительности выявят проблемы.

3. Построение отчета — это то, на что, как я заметил, уходит львиная доля времени. Запустите трассировку SQL во время создания отчета. Настройка и отображение даже относительно простых таблиц с большим количеством данных может занять около минуты (HTML через apache tomcat) после того, как трассировка SQL укажет, что запрос выполнен.

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

4. Способы доставки PDF, Excel, HTML могут иметь разные проблемы

   • попробуйте использовать отчет в разных форматах
   • если один из них значительно больше, попробуйте другие источники.

Для всех, у кого еще есть проблемы с производительностью BIRT, вот еще несколько советов.

• Профилирование отчета BIRT можно выполнить с помощью любого профилировщика Java — напишите простой Java-тест, который запускает ваш отчет, а затем профилируйте его. В качестве примера я использую модульные тесты из SpudSoft BIRT Excel Emitters и запускаю JProfiler из Eclipse. Проблема не в сложности его профилирования, а в понимании полученных данных 🙂

• Скрипты, связанные с источниками данных, могут полностью снизить производительность. Даже сценарий, который выглядит так, как будто он должен оказывать влияние только на начальном этапе, действительно может остановить это. Это самый большой убийца производительности, который я нашел (настолько большой, что я переписал значительную часть источников Excel, чтобы сделать это ненужным).

• Используемый вами эмиттер оказывает влияние. Если вы пытаетесь сузить круг проблем с производительностью, всегда выполняйте отдельные задачи запуска и визуализации, чтобы вы могли легко видеть, на чем сосредоточить свои усилия.

• Различные параметры источника могут повлиять на производительность, особенно в случае сторонних источников (в источниках SpudSoft теперь есть несколько опций для ускорения создания больших отчетов).

• Разница между фиксированной компоновкой и автоматической компоновкой существенна, попробуйте обе.

Вы проверили, сколько памяти вы используете в Tomcat? Возможно, вы выделяете недостаточно памяти. Быстрый тест заключается в запуске BIRT Designer и выделении ему дополнительной памяти. Затем запустите отчет в программном обеспечении BIRT Designer.