- выпадак першы
- выпадак другой
- Аналіз вынікаў для першага выпадку прыкладу.
- Аналіз другога выпадку
- Сцэнары (спосабы) аптымізацыі
- Прыклад аптымізацыі для ўмоўнага тыпавога выпадкі
- Параўнанне спосабаў аптымізацыі
- Шаблоны ABAP і спосабы аптымізацыі
- Сферычны прыклад.
У любой SAP сістэме ёсць Z-код і, натуральна, ёсць Z-код, які працуе павольна. Паняцце «павольна» - адносна, дзесьці гэта можа быць гадзіннік або нават дні, а дзесьці хвіліны ці секунды. Праца на платформе SAP HANA дазваляе з невялікімі працавыдаткамі паскорыць «доўга» працуюць праграмы і дасягнуць патрабаванай прадукцыйнасці, нават калі гэта секунды.
Алгарытм (этапы) аптымізацыі ABAP-праграм:
Вызначэнне KPI - у колькі разоў павінна быць паскорана праграма або патрабаваны час працы пры пэўных умовах запуску.
Выкананне аналізу прадукцыйнасці - выкананне праграмы на пэўных умовах запуску і збор статыстыкі выканання аператараў.
Вызначэнне вузкіх месцаў і спосабаў іх аптымізацыі.
Аптымізацыя праграмы.
Паўтарэнне пунктаў 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:
абмежаваны доступ
Для чытання поўнай версіі артыкула неабходна зайсці як зарэгістраваны карыстальнік.
