现在的位置: 首页 > 综合 > 正文

SAP Performance浅析

2013年10月10日 ⁄ 综合 ⁄ 共 7300字 ⁄ 字号 评论关闭
文章目录

本文来源于:http://scnblogs.techweb.com.cn/tcsapbw/archives/1061.html

在ABAP开发中,Program的Performance tunning应该说是最基本也是最常见的工作内容,无论是在新项目的开发、还是老项目的maintainance。同时,关于performance,也是ABAP面试中几乎必问的问题之一。在performance这方面,SAP提供了专门的BC490课程以及相关跟进的training。

同时,Performance以及程序优化乃至代码重构(Refractory)也是一项非常非常有技术含量的工作,自己也仅所知所学皮毛而已,还有相当相当多的知识需要加深入学习。

这里,修改了自己以前的一份总结,重新记录一下,以加深印象以防遗忘。

以下记录过程中,使用测试程序:

*&———————————————————————*
*& Report  ZTEST_PERFORMANCE_1
*&
*&———————————————————————*
*& For Performance Tunning
*&
*&———————————————————————*

REPORT ZTEST_PERFORMANCE_1.

data:
ls_scarr type scarr,
lt_scarr type table of scarr,
ls_spfli type spfli,
lt_spfli type table of spfli,
ls_sflight type sflight,
lt_sflight type table of sflight.

data:
lw_num1 type i,
lw_num2 type i,
lw_num3 type i.

data:
lw_tmp type i.

* main program
start-of-selection.
WRITE:/ sy-UZEIT.

*1. retrieve data from scarr
select * from scarr into table lt_scarr.
describe table lt_scarr lines lw_num1.

DO 100 TIMES.

loop at lt_scarr into ls_scarr.
“2.retrieve data from spfli
select * from spfli into table lt_spfli
where CARRID = ls_scarr-carrid.
lw_num2 = lw_num2 + 1.

loop at lt_spfli into ls_spfli.
“write:/ ’Carrid:’, ls_spfli-carrid,
“        ’Connid:’, ls_spfli-connid.
“uline.
“3. retrieve data from sflight
select * from sflight into ls_sflight
where CARRID = ls_spfli-carrid and
connid = ls_spfli-connid.
“ write:/ ’Carrid:’, ls_sflight-carrid,
“       ’Connid:’, ls_sflight-connid,
“      ’FLDATE:’, ls_sflight-FLDATE.
lw_num3 = lw_num3 + 1.
endselect.
endloop.

endloop.

ENDDO.

write:/ ‘Scarr Records:’, lw_num1,
/ ’spfli Records:’, lw_num2,
/ ’sflight Records:’, lw_num3.

在这个程序中,人为多循环了100次。

最后执行结果:

116

1. 使用STAD:SAP WorkLoad Business Transaction Analysis

Tcode: STAD.

使用该Tcode得到single program/transaction运行时总体分析数据。

其中,关于时间的概念:

213

其中,我们最经常用的是Response Time, DB time以及CPU time.

当拿到一个结果分析数据后,可以按以下的方案进行初步地判断后续应继续Trace何种结果。

|- CPU time > 40%(Response time - Dispatcher wait data) ==>Se30: Runtime Analysis

  • 引起该结果的是由于一些ABAP process,例如Loop等

|- Database time > 40%(Response time - Dispatcher wait data) ==>St05: SQL Trace

  • 引起该结果的是由于大量的直接操作数据据等

其中,这里,很多时候,我们就是直接使用的Response Time作为基数。

例如上面自己的例程中,使用STAD可以得到如下的结果(注意:在进行筛选时系统时间方面,一定是Application server的时间,而非自己presentaion server的时间)

311

2. 使用SE30: ABAP Runtime Analysis

(1)SE30简介

Tcode: SE30.

使用该工具主要用于Transaction或program背后ABAP的运行时分析,比如分析哪步运行耗时最多,并通过分析得出为什么、然后进行代码优化。

使用SE30主要分三步进行操作:

(1) 设定需要Trace的数据范围

决定将要分析哪些object哪些data哪些process等等.同时很重要的是,决定最后分析结果的“粒度”(Type of aggregation: Full aggregation, aggregation per calling position, no aggregaion).

这些是通过设置SE30运行时的variant来实现的。

(2) Trace 跟踪

现在使用SE30可以直接从SE30进入到所经Trace的Transaction/Program中(同一个user session),也可以在另外的user session中通过menu中的active runtime analyze等方法来trace跟踪.

(3) 分析结果

分析SE30的结果时,我们一般采取的是“渐进”的方式:先使用full aggregation可以得到程序的主要的FMs或者逻辑处理单元;然后再细化一下分析粒度,aggregation per calling position,甚至no aggregation,这时就可以得到最详尽的统计分析信息: table list, hierarchy等等。

以下是SE30的初界面:

44

其中关于in Parallet session中,再补充一下,平时也用到了:

按纽 “Switch on/off” of “In parallel session”

将会有一个screen appears listing all r/3 work processes running on the current application server. To switch on runtime analysis for the object,选中它然edit==>measurement==>switch on/off

其中完成上面第一步的设置,可以进去进行设置,这里不再赘述;这里仅记录一下aggregation粒度的使用,这也是我们平时使用SE30最最基本的操作,因为设置它对我们analysis实在是太重要了,深有体会呀。

54

(2)使用SE30分析程序

分析上面自己的程序。

这里仅是一次简单记录,使用的aggregation level是no aggregation.

65

点击execute执行:

程序会正常执行。最后返回到SE30:

163

这里,也可以使用other file去选择自己trace后的数据(注意,关于这些结果文件的保存:如果保存在当前的Application server上的file system里,那么最大到 8 天时间);点击evalute:

84

好,从这张结果图上,我们可以得出非常重要的信息:

一目了然:本程序中DB Time消耗掉绝大部分时间,达到95%以上。所以,主要问题出在了读写数据库上,后续优化需从这方面考虑(比如再进行ST05,然后寻找更佳解决方案).

另外,注意,最上面那一排的button提供了更为详细的分析工具,利如table list, hit list,herarchy 等等(但是注意,这是与在variant中设置的aggregation level相关的)。

Hit list

A list of all called program parts or instructions, sorted according to gross time.It contains one row for each program part,包括name of the program part, gross time, net time,以及number of times this part was called.

Group hit list

A list of individual calls of instructions grouped according to instruction categories(如forms, FM, methods),包括gross run time and the number of times the instruction was called.

Table hit list

A list showing accesses to DB tables,包括access name, number of accesses, table type,buffering mode以及一些其他信息

Hit list of internal tables

A list of all internal table accesses that indicates the internal name, the number of accesses, the gross and net time taken(absolute value and percentage), the memory required, and other info.

Call hierarchy

A list showing the chronological sequence of analyzed objects, indicating the gross and net time taken and the call level.

例如,我们上面的分析结果中,就看hit list:

94

这里,关于时间:

  • Gross: 整体执行相关Functions时的时间,例如如果一个FMs里面再调其他FMs,那么它将记录自己FMs执行时间再加上被调FMs时间
  • Net:本身执行的时间(也就是Gross – 相关的FMs等时间)

所以,上面的结果,给我们提供了重要的信息是:

对表SFLIGHT的Fetch(对应着open SQL: select)花掉时间最多,同时对表SPFLI的检索同样花掉相当多的时间。

然后,也可以通过上面的Display Source code按纽去直接查看相关的代码。

当然如table list,hierarchy list等可以提供更多Performance相关的信息,具体可以以进行测试并分析。

3. 使用ST05: SQL Trace

(1)ST05简介

Tcode: ST05.

其实ST05不光是提供SQL Trace,它还具有如: Buffer trace, Enqueue trace以及RFC trace。这里仅记录在工作中使用最广泛的SQL Trace。

另外,这里有一点需要值得记录:因为有些DB Table是具有buffer机制的,所以,在进行ST05前,最好是先运行一次,以填充Buffer(关于Table buffer,后面将会有新的一篇专门作简要介绍)。

另外在执行SQL trace时,也需要确认自己没有运行其他的session动作(如backgroud job等)在一个application server。同时,在一个给定的application server,只能由一个user来active a trace。它的default size 是800KB.可以通过设置parameter:rstr/max_diskspace到16384000来达到16MB.

ST05 Trace的结果格式:

hh:mm:ss.ms

time stamp of begin of sending the database request

Duration

操作的总时间in microseconds

Progrm

运行的程序

Object

name of table or view, in the SQL statement

Oper

database operation to be executed

Curs

Name of the databse cursor

ArrSz

size of packets containing the data records sent from DB server to Appliation server

Rcc

number of data records sent by Database operation

RC

return code of db system

Statement

text of the SQL statement

对于Trace,最常遇到的问题就是ABAP中的open SQL与trace结果中的语句不明白。这里简要记录一下:

对于一次DB Read操作需要做的operations:

(1)Prepare:

(2)Open/Reopen

(3)Fetch

而对于一次DB Write操作,同样是这样的三步过程,但是这里不是open/reopen and fetch而是Exec/Reexec(另外注意,因为会使用database buffer所以,对于相同的sql statement,reopen一般会被ommit)。

在ST05的结果分析中,有很多的options可以供我们进行利用:

  • Explain SQL

它是非常有用的工作,可以供我们分析某一条语句在底端数据库中是如何执行的(注意:它仅对“Prepare”,”open”和“reopen”有用)。这将在后面有一篇介绍cluster table与pooled table中有充分地使用该功能。

  • Goto–>Summary

Display a summarized form of the list. 当需要找到LOOP这样的结构时,它非常有用. 另外,当点击”Summarize”时,可以得到操作最频繁的。

  • Goto–> Statement Summary

它非常有用:找到structure-identical SQL。同时,也能够给出value-identical SQL所占的比例。

关于Structure-identical SQL与value-identical SQL,这也是平常使用ST05时最关心的几个指标之一:

  • Structure-identical SQL:它是指SQL结构是一样的,而用于检索的variable的值是不一样的。
  • Value-identical SQL:它是指SQL结构、用于检索的variable的值都是一样的。

举个简单的例子:

如SQL 1: select * from <table1> where F1 = <variable1_1>

SQL 2: select * from <table1> where F1 = <variable1_2>

那么,如果这里的<variable1_1> 与<variable1_2>不相等, 则为structure-identical SQL;如果相等,则为value-identical SQL.

从这里可以看出,一般出现structure-identical是在loop中套select,所以这里候应该思考是否可以先一次从DB读取完,然后再在LOOP中使用read 内表。

而value-identical的sql应该使用诸如内表等,坚决避免。

最后,我们一般使用ST05的方法或者策略:

一般开三个session:

(1) 一个session for trace list

(2) 一个session for compressed summary

(3) 一个session for identical selects

在分析list时:

(1)如果一个sql statement的operation需要超过200000 ms或者require 10 fetch那么可视为expensive

(2)对于structure-identical的sql statemenet,考虑是否会有nesting(例如,出现这种sql一般会在loop中使用select等。这时就会出现structure-identical sql)

(3)对于value-identical的sql statement,应尽量避免

(2)使用ST05分析程序

分析上面自己的程序。

ST05。点击Activate Trace:

104

另外一个session然后运行自己程序:

117

结束后,回到ST05,点击deactivate Trace

124

然后点击display trace并search刚记录的trace:

134

从这个trace list中,我们可以得到SQL 语句one by one,很清晰地知道这本程序的SQL执行情况。

选择一行,点击explain,可以得到这一句SQL在DB层是如何执行的,并同时可以得到这个table的primary inde等相关的情况。

同时通过Trace list–> Summarized SQL statemeent,可以得到按table summarized 的SQL情况:

143

例如从上面就可以看到对SFLIGHT表操作中有99笔是identical的。

然后通过trace list–>identical SQL 可以很清晰知道本程序中有哪些value-identical的SQL语句:

153

从这里可以得出,重复的数据被重复读取了100次。

注:ABAP Performance的Tunning是一件相当复杂并有challenge的工作。这里仅记录了非常简单的一般常用的三种performance相关的工作(STAD,ST05,SET30),同时各个工具也没有深入去记录它们里面强大的功能。深入学习,还需查阅相关技术文档。

抱歉!评论已关闭.