База знаний

Анализ производительности ABAP программ

Алексей Рычков

17637

10

Распечатать

1.     Описание работы транзакции ST12

Транзакция ST12 описывается ниже в объеме, необходимом для анализа производительности программного кода. После запуска транзакции ST12 система выведет на экран диалоговое окно (Рис.1).

Рис.1 Диалоговое окно транзакции ST12

Ниже описываются используемые для анализа инструменты.

• Набор кнопок «Trace for»:
  • Кнопка «Current mode» (Вариант трассировки). Используется для трассировки программы или транзакции.
  • Кнопка «Workprocess». Используется для трассировки рабочих процессов (см транзакцию SM50) (удобно для трассировки фоновых заданий или анализа на определенном сервере).
• Фрейм «Назначение объекта трассировки». На рисунке 1 назначена программа ZKPERFOMANCE .
• Фрейм «Виды трассировок». На рисунке 1 отмечены опции: ABAP trace и Performance traces for SQL.
• Фрейм «Архивы трассировок»
• Кнопка «Обновить». Анализы трассировок доступны не сразу, необходимо время для их сбора. Эта кнопка позволяет обновить статус для Trace analyses.
• Набор кнопок «Evaluate».

Выбор варианта анализа трассировки. Кнопка «ABAP trace» позволяет просматривать результаты трассировки, которые соответствуют результатам транзакции SE30, кнопка  «Performance trace» - транзакции ST05.

2.     Анализ программы ZKPERFOMANCE.

Для анализа производительности используем вариант, как указан на рис 1 (выбраны ABAP trace, Performance Trace - SQL). Для запуска трассировки нажимаем кнопку «Execute/start trace».

После нажатия кнопки, переходим на начальный экран анализируемой программы. Задаем условия на селекционном экране. Выполняем программу.

Система выведет на экран результат трассировки (рис.2). Статус "свечка" означает, что результаты в процессе обработки, значок "галочка" означает, что результаты трассировки собраны. Обновляем в ожидании готовности.

Рис. 2 

Выбираем трассировку и начинаем анализ.

Важно: Трассировку необходимо проводить от начала и до конца работы транзакции. Если прервать трассировку, результат не будет соответствовать действительности. Всегда выбирайте вариант транзакции такой, чтобы он отрабатывал менее чем за 20 минут. Через 20 минут SQL trace будет остановлен системой.

ABAP trace.

Для начала отсортируем таблицу по полю Net(%), чтобы выяснить, какие вызовы требуют большее количество времени.  Анализ обычно проводиться для первых 2-4 тяжелых вызовов. Для дальнейшей оптимизации трассировку можно снова повторить.

В данном случае видно, что время выполнения программы 10 сек из них 9 сек тратиться на базу данных Database, и база данных самая низкая по производительности, т.к. ее работа связана с обращением к файловой системе, ABAP выполняется на сервере приложений, в оперативной памяти.

Performance trace.

Необходимо вывести все строки трассировки. Обнаружено множество идентичных запросов, поэтому следующим шагом нужно суммировать результаты, меню Trace list - Summarize trace by SQL Statement.

В данном случае результат трассировки соответствует анализу в ABAP (Запросы к MAKT и VBAP в топе). Важной особенностью этой трассировки является анализ работы оптимизатора SQL запросов. Преобразованный из ABAP в специфичный SQL для базы  данных запрос можно посмотреть по кнопке Expalain. В плане выполнения (execution plan) можно увидеть насколько оптимально простроен запрос. На основании плана можно оптимизировать запрос на уровне базы данных, например добавить индекс или применить database hits, если оптимизатор ошибочно строит запрос.

В данном примере видно, что запрос к таблице MAKT построен оптимально, и использует уникальный индекс MAKT~0. Как анализировать план выполнения можно почитать в ноте <766249>. В данном варианте анализа я не буду рассматривать SQL trace, т.к. анализ сводится у умению читать план выполнения запроса. Типовыми методами оптимизации SQL на уровне плана являются: добавление индексов; использование databse hints, применяется обычно, когда план запроса является не оптимальным; как вариант необходимо пересмотреть запрос в целом.

Описание найденных проблем.

1.         Тяжелый SQL запрос к таблице MAKT

Обнаружен тяжелый SQL запрос к таблице MAKT. Хотя сам план выполнения запроса построен оптимально, по результатам трассировки видно, что обращений к таблице MAKT было 16 тыс. раз. Дальнейший анализ показал, что обращение к таблице происходит в конструкции LOOP ... ENDLOOP.

  LOOP AT it_vbak ASSIGNING <fs_vbak>.

    SELECT SINGLE * FROM makt