Оптимізація ABAP програм на SAP HANA / Сапер / Статті / База знань / SAPLand - Світ рішень SAP

1. випадок перший
2. випадок другий
3. Аналіз результатів для першого випадку прикладу.
4. Аналіз другого випадку
5. Сценарії (способи) оптимізації
6. Приклад оптимізації для умовного типового випадку
7. Порівняння способів оптимізації
8. Шаблони ABAP і способи оптимізації
9. Сферичний приклад.

У будь-який SAP системі є Z-код і, природно, є Z-код, який працює повільно. Поняття «повільно» - щодо, десь це може бути годинник або навіть дні, а десь хвилини або секунди. Робота на платформі SAP HANA дозволяє з невеликими затратами прискорити «довго» працюють програми і досягти необхідної продуктивності, навіть якщо це секунди.

Алгоритм (етапи) оптимізації ABAP-програм:

1. Визначення KPI - у скільки разів повинна бути прискорена програма або необхідний час роботи при певних умовах запуску.

2. Виконання аналізу продуктивності - виконання програми на певних умовах запуску і збір статистики виконання операторів.

3. Визначення вузьких місць і способів їх оптимізації.

4. Оптимізація програми.

5. Повторення пунктів 2-4, аж до отримання заданого KPI або до визнання неможливості його досягнення.

Процес оптимізації може виявитися майже «нескінченним» і, природно, дуже трудомістким. Щоб уникнути додаткової роботи, необхідно визначити умова завершення циклу оптимізації, або KPI. Прикладом KPI може бути: програма повинна прискоритися в 100 разів або програма повинна відпрацьовувати не більше 10 секунд. Звичайно ж KPI повинен бути реалістичним. Також KPI повинен враховувати параметри запуску програми: наприклад, на невеликих обсягах даних (наприклад звіт за 1 місяць) різниця в часі роботи з базою даних на HANA, і не на HANA може бути незначна і оптимізація зажадає значних трудозатрат, а на великих обсягах даних ( річних) ця різниця буде значно більше. Природно, дані повинні відповідати бізнес-процесу (не потрібно виконувати звіт за кілька років, якщо він запускається завжди за один рік).

Приклад вибору KPI роботи програми

У таблиці (Рис.1) показані варіанти вибору KPI.

Рис.1 Варіант вибору KPI

Аналіз продуктивності це - збір статистики по часу виконання операторів ABAP програми.

Я рекомендую виконувати аналіз продуктивності в транзакції ST12, ця транзакція розроблена SAP AGS (SAP Active Global Support) для комплексного аналізу продуктивності ABAP. Можна використовувати транзакцію SAT (стара SE30), якщо комусь подобатися.

Більш докладно про ST12 в моїй статті http://sapland.ru/articles/stats/2013/1/analiz-proizvoditelinosti-abap-programm.html .

Важливою особливістю транзакції з аналізу продуктивності є обмеження по часу збору даних і розміром файлу, куди записуються дані трасування, якщо перевищити цей ліміт, то результат трасування буде нерелевантних і, відповідно, неадекватним. Таким чином, для тривалих транзакцій рекомендується запускати аналіз з параметрами, щоб програма працювала близько 20 хвилин, в такому випадку ми отримаємо повну трасування, розподіл часу роботи по операторам, близьку до реального, при цьому трасування НЕ буде дуже трудовитрат.

Після трасування, необхідно відсортувати результати по полю Net (%) по спадаючій. Для нас цікавий топ 3-5, в залежності від розподілу часу і, бажано, щоб виклики припадали на Z-код.

випадок перший

На рис.2 скріншот результату трасування тестової Транзакції 1, топ 3

Мал. 2 Результат трасування Транзакції 1 в ST12

У розглянутому випадку 50% часу програми займає запит до таблиці AUSP в Z-області. І 16% - виклик ФМ READ_TEXT, який складно оптимізувати.

випадок другий

На рис.3 скріншот результату трасування тестової Транзакції 2, топ 3

Мал. 3 Результат трасування Транзакції 2 в ST12

У другому випадку (Рис ... ..) 51% часу роботи займає запит в циклі до таблиці MATERIALID, виклик зі стандартної програми, а 27% часу займає запит в циклі до таблиці IFLOS. У таких випадках проводимо аналіз стека виконання.

Мал. 4 Аналіз стека виконання операторів для Транзакції 2 в ST12

Ми бачимо, що проблемний код знаходиться в BAPI, який викликається у впровадженні BADI. Так що, потенціал оптимізації є, десь на 70%.

Після збору трасування необхідно проаналізувати вузькі місця в продуктивності програми, і потім розробити план оптимізації.

Аналізу продуктивності коду програми ABAP присвячено кілька курсів SAP, книги, статті в інтернеті. Маємо багато різноманітних ситуацій,, які складно описати в статті або навіть книзі. коли програма ABAP має низьку продуктивність Для повного розуміння всіх тонкощів ABAP потрібно прочитати вельми багато курсів, книг і мати великий досвід програмування на ABAP.

Проте, я розгляну деякі основні шаблони ситуацій:

Таблиця 1

Аналіз результатів для першого випадку прикладу.

Результат трасування наведено для тестової Транзакції 1

Мал. 5 Результат трасування Транзакції 1 в ST12

Дивимося ABAP код

Бачимо важкий, особливо для SAP HANA, запит SELECT ... FOR ALL ENTRIES

Аналіз другого випадку

Рис.6 Результат трасування Транзакції 2 в ST12

Виклик BAPI в циклі (майже 200 тис. Разів) в якому надлишкові запити

Мал. 7 Місце виклику BAPI. Яка є причиною низької продуктивності

Сценарії (способи) оптимізації

Існує два сценарії використання HANA: «ABAP on HANA» і «HANA акселератор через secondary DB connection».

• Найзручніший випадок, коли ABAP on HANA, тоді ми можемо використовувати External view і ADMP (в минулому Database Proxy), а самі ABAP OPEN SQL запити виконуються в HANA, так само ми можемо використовувати Core Data Service замість HANA View

• Варіант з HANA акселератор складніший і вже екзотичний, тому що ми обмежені в використанні збережених процедур (немає можливості передати масив даних (внутрішню таблицю) в параметри збереженої процедури), приходиться перетворювати SELECT-OPTIONS в умова WHERE. Якщо не вистачає оптимізації ABAP (SELECT ... CONNECTION), тоді необхідно переносити логіку ABAP програми в HANA Calculation view.

Приклад оптимізації для умовного типового випадку

Є програма, трасування в якій показала низьку продуктивність в циклі LOOP

Програма не переписується цілком, ми замінили повільний цикл на виклик ADMP (збереженої процедури), логіка циклу перенесена в збережену процедуру

Той же випадок, але c використанням HANA акселератор; довелося переписати всю програму на HANA view, що більш трудомісткий.

Порівняння способів оптимізації

• Оптимізація ABAP - найстаріший спосіб, особливо він корисний, коли HANA використовується як акселератор, іноді досить направити запит в HANA (SELECT ... CONNECTION) і вже досягти істотних результатів.

• Оптимізація з використанням HANA збережених процедур - дуже зручно, при використанні ADMP, дозволяє швидко оптимізувати проблемний код, без редизайну всієї програми зручно для передачі внутрішніх таблиць, але не зручно використовувати і передавати умови WHERE

• Оптимізація з використанням HANA Calculation Engine (graphical в нашому випадку) - один з найбільш трудомістких способів оптимізації, має сенс для оптимізації великих проблемних ділянок програм або для повного перенесення логіки ABAP в HANA, але при цьому отримуючи значне прискорення (в сотні разів). Для обмеження даних в HANA view (як Exteranl view) можна використовувати SELECT-OPTIONS.

Оптимізація з використанням Core Data service (CDS) - те ж саме, що і HANA View, але більш гнучке за рахунок використання SQL, рекомендується використовувати замість HANA View Нижче розглянемо деякі типові ABAP шаблони і як їх можна оптимізувати (перенести в HANA)

Шаблони ABAP і способи оптимізації

Таблиця 2

Загальна рада.

Вся обробка даних - це вибірка, об'єднання або агрегація даних. Тому намагайтеся уявити логіку даних в цьому виді. Далі спробуйте перенести логіку з ABAP на звичайний SQL, гугл допомагає. Далі, якщо використовуєте CE і CDS, цей SQL можна перенести в CE функції.

Сферичний приклад.

ABAP:

Обмежений доступ

Для прочитання повної версії статті необхідно зайти як зареєстрований користувач.