Performance Analysis Tuning

ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 1

Dr. Ulrich MarquardSAP AG

Performance Analysis & Tuningor:

How to Ensure Scalability

of mySAP.com


Agenda

Locks on Central Resources

Optimal Use of Central Resources

Share(d) Memory

Guidelines forGuidelines for ServerServer ProgramsPrograms

Parallelization

Optimized Communication

"Linear" Programming

o


Scalability on the Autobahn to Walldorf

If you were to optimize throughput of an Autobahn ...

• Avoid traffic jams

• Have signs in front of toll stations sothat everybody can get the rightamount of money

• If a hazardous truck is under way,ensure it doesn't block other lines

• If that truck must block other lines,make sure it's for a very short period oftime outside the rush hour

• Make sure three lines are openeverywhere

• In case of road works narrow lines, butstill keep the number

• Avoid bents or dangerous slopes, itslows the traffic down

• Promote car sharing

• Avoid locks on central resources

•If a lock on a central resource isnecessary, keep the locking time asshort as possible

• Try to use central resources asseldom as possible

• Use central ressources as effectiveas possible

• Avoid single points of failure

• Try to parallelize

• Share and reuse data


Agenda



Share(d) Memory

Guidelines for Server Programs

Parallelization



o


Exercise 1

ÿ How long does it take to create 100,000 documents

� On a 12-way database server

� If you need document numbers without gaps ordered by time

� The time intervall between creating the document number andCOMMIT WORK is 100 ms

ÿ Is there any difference, if ordering by time is not required?


Locking and Performance

ÿ Locks (enqueues and DB locks) on central objects can serializerunning transactions

ÿ Avoid serialization

� "Lock as much as necessary but as little as possible"

� "Lock as long as necessary but as short as possible"

� Example number ranges: less requirements �� less serialization

� Example ATP: additional logic can help reduce locking times,especially over dialog steps

� Reducing serialization is more important than optimizing run time

ÿ General rule for the database� INSERTs come first

� UPDATEs in highly aggregated tables come last

ÿ For many enqueues use bundling (local enqueue container)

� First lock, then read to ensure data consistency

ÿ Keep locking times as short as possible by using array operations instead of singlerecord inserts/updates.

ÿ Avoid serialization: the follow-up slides show examples.

ÿ The usage of enqueue bundling is explained in the online help.


DB Locks Ensure Consistency of DB LUWs

Lock on record in TAB1



0.1 - 10 s (even hours)

CommitRollbackCommit

INSERTTAB 1

time

Table 1

INSERTTAB 2

UPDATETAB 3

Table 2

Table 3

Releasesall locks

ÿ DB locks ensure consistency and isolation of the DB LUWs

ÿ The database locks:

�all data that are changed (INSERT, UPDATE, DELETE, SELECT FOR UPDATE) during a DB LUW.

�are released on commit or rollback of the DB LUW. All other DB LUWs must wait until commit orrollback of the DB LUW.

�not only application relevant data.

� indexes but sometimes with a coarser granularity (e.g. at page/block level).

ÿ Depending on the read consistency (Committed read), even SELECTS have to waituntil the Commit/Rollback. By default SAP uses dirty read on the database andensures read consistency by SAP ENQUEUES

ÿ To better parallelize processes, all updates on central records should occur at the endof the DB LUW.


Example for Lock Situations

CreateOrder 1

User 1

Rollback

ChangeOrder 1

User 2

DirtyRead

ENQUEUEOrder 1

User 1

ENQUEUEOrder 1

User 2

CreateOrder 1

Return Code=4: Wait

DEQUEUEOrder 1

ReadOrder 1


ÿ Is executed during COMMIT WORK

ÿ This mechanism can be used in two places during a SAP LUW:

� In the dialog part (COMMIT WORK)

� In the update task (implicit COMMIT WORK of the update workprocess)

ÿ PERFORM ... ON COMMIT LEVEL commit_level

Pre-aggregation of Data

COMMIT WORK

SAP LUW - dialog update task

Screen

PERFORM ONCOMMIT

Screen Screen

PERFORM ONCOMMIT

PERFORM ONCOMMIT

PERFORM ONCOMMIT


Example: Shorten DB Lock Times I

COMMIT WORKsingle inserts……………..………………...

appends to internal table…….............….

SORT internal tableINSERT FROMinternal table

ABAP

Database

ABAP

Database Long DB Locks

Short DB Lock

DB LUW

Don't

DO


Example: Shorten DB Lock Times II

COMMIT WORK

DB LUW

single updates……………………………………...

collects to internal table ……………………….

SORT internal tableLOOP AT internal

table update setwhere...ABAP

Database

ABAP

Database

Don't

Do


Example: Shorten DB Lock Times (Code)

Process

Loop at documents....

Perform post_total_records.Endloop.

Forms

Form post_total_records.

Collect glt0 to i_glt0

Perform post_records_go on commit

Endform.

Form post_total_records_go.

Sort i_glt0 by mandt ...

Loop at i_glt0.

Update glt0 set a = a + i_glt0-a

...

Where ...

Endloop.

Refresh i_glt0.

Endform.


Example: Number ranges

ÿ Number ranges generate unique identifiers for applicationobjects

� No buffering(one single table row for number range)

� can lead to massive serialization

� numbers are consecutive and no numbers get lost

� "Buffer" in local file(one single table row for each number range and application server)

� better performance but serialization still possible

� no number is lost

� Buffer a couple of numbers in shared memory on app. server

� no locks, optimal performance

� order of numbers is arbitrary, numbers may be skipped / lost

� sufficient for most applications

ÿ No bufferingA SELECT SINGLE FOR UPDATE on a record in table NRIV where, for each numberrange, there is an active number range interval. Therefore transactions accessing thesame number range all lock the same record.

ÿ Buffer in local fileA SELECT SINGLE FOR UPDATE on a record in table NRIV_LOKAL, which containsthe application server name as an additional key field. Thus transactions running ondifferent application servers do not collide, but transactions from the same applicationserver do. The records in NRIV_LOKAL contain several numbers which are ‘filled’ fromNRIV.

ÿ Buffer in shared memory means that each transaction reads a number from a sharedmemory area. On demand, this memory is ‘filled’ from NRIV using anothersynchronously called work process. This second work process reads from NRIV usingSELECT SINGLE FOR UPDATE, but updates and commits this change immediatelybecause it is running in an independent DB LUW.


000 FI_BELEG 01 1999

000 server1 FI_BELEG 01 1999000 server2 FI_BELEG 01 1999000 server3 FI_BELEG 01 1999000 server4 FI_BELEG 01 1999

Example: Layout of NRIV and NRIV_LOKAL

Significance of temporal locks

CLIENT OBJECT SUBOBJECT NRRANGENR TOYEAR

CLIENT INSTANZ OBJECT SUBOBJECT NRRANGENR TOYEAR

NRIV has 5 key fields

NRIV_LOKAL has 6 key fields


Example: ATP (Availability To Promise)

If decision = yesthen amnt = amnt - req

Check availability(req <= amnt)

ABAP

Enqueues

Screen Screen

Decide

ABAP

Enqueues

ScreenScreen

Check availability(req <= amnt - (req1 + req2 + …))and store req as reqn

Decide

If decision = yesthen amnt = amnt - reqnelse forget reqn

… all others check availability as(req <= amnt - (req1 + req2 + ... reqn))

SAP LUW

Lock

AdvancedLockingFeature

ÿ The example of ATP shows how knowledge about the application logic can beexploited to reduce contention due to enqueues.

ÿ The upper figure represents a "straight forward" implementation of ATP. An enqueuehas been used to lock the amount of the requested material for the whole time fromthe check until the end of SAP LUW (end of update task). This can possibly includemany dialog steps, and can lead to massive serialization if a small number of materialsis frequently requested.

ÿ In the current implementation, the enqueue is used during the ATP check itself andwithin the update phase. In both cases, no dialog time (user think time) is includedwithin the locking time. The information about the requested amount is stored in theenqueue server. From there, it is read for all following checks and also in the updatephase to calculate the resulting amount.


Benefits of SAP ENQUEUES

ÿ Locking on business object level, not on database table level

� Lock granularity can be smaller than one table row

� Lock time can be shorter than database transaction

ÿ Locks can be inheritet to other processes (update task)

ÿ Locks can contain additional (business) information

ÿ Array processing is possible by bundling enqueues


Transmits a set of enqueue requests simultaneously

Loop at itab.Call Function 'ENQUEUE_OBJECT1'

exporting VAR1 = itab-field1_COLLECT = 'X'.

CALL Function 'ENQUEUE_OBJECT2'exporting VAR2 = itab-field2

_COLLECT = 'X'.Endloop.Call Function 'FLUSH_ENQUEUE'.

Bundling Enqueues


Lock Management Monitoring

DB01 Database Locks

SM66 System-wideOverview

ST05 PerformanceTrace

SM12 EnqueueOverview

ST05 PerformanceTrace

SAP DB


Exercise 2

ÿ System: M13

ÿ Client: 900

ÿ User: DSZ400-26 ---------- DSZ400-75

ÿ Passwort: INIT

ÿ Servernames: 426 ----------- 475

ÿ Please use the last two digits of server name foryour user name


Exercise 2

ÿ Analyse and optimize program that creates documentnumbers (DSZ400_NUMBER_GET_NEXT)

ÿ Use ST05 and DB01 to identify the locking time and the resource being locked

ÿ How can the throughput be optimized?


Agenda



Share(d) Memory

Guidelines for Server Programs

Parallelization



o


TableBuffers

Dispatcher

SPOWP

BTCWP

DIAWP

TableBuffers

Dispatcher

DIAWP

ENQWP

EnqueueTable

SAPGUI

SAPGUI

SAPGUI

SAPGUI

SAPGUI

DBWPDBWPDBWP DBWP

GatewayGateway

FrontendApplication(e.g. Word)

Runtime Environment - Figures

Access Times Memory Consumption Data / Dialog Step

20KB

Approx.2KB

0.1ms

1ms

10ms

20KB

Approx.2KB

10GB - 500+ GB

500 MB

50 MB

5MB

ÿ Access times:

�Read from buffers is about 0.1 ms.(Reading from internal tables is about 10 times faster but this data is stored once per each runningprogram! See also the buffering section.)

�Read from database is about 1 ms (assuming the data is cached in the DB cache which holds truefor 95% of all cases).

�Read from database (with file I/O) is about 10 ms.

ÿ Memory consumption:

�Program context: about 5 MB for a dialog transaction which is run by many users concurrently. Forbackground jobs and transactions run only one at a time, other sizes might apply.

�Buffer sizes (table buffers): about 50 MB.

�Database data: 50 GB (database cache: about 500 MB).

ÿ Data per dialog step:

�Application server to SAP GUI: about 2 KB, when using new technologies or transferringdocuments this can be much higher.

�Database to application server: about 20 KB.


Exercise 3

ÿ An application program processes 200 SQL statements

ÿ It has a minimum run time of 1s

ÿ 90% of those statements access configuration tables

ÿ How much can you

1. Reduce the minimum run time if you use table buffers?

2. Increase the maximum throughput if you use table buffers?


Rules for Programming in Open SQL

Keep the result set small

Reduce the amount of transferred Data

Reduce information transfer to the application server

Keep the area to be searched small

Make optimal use of the SAP buffers on the applicationserver

1

2

3

4

5

ÿ If all else fails and the right index is not used, consider database hints


Index: field1

field2

SELECT field1 field2 field3FROM table1WHERE field1 IN ('A','B') AND field3 like 'T%'

SQL is set-oriented

SELECTclause

WHERE clause

FROM clause

search area

One or more tables

Data which must besearched through -

limited only bythe use of indexes

The result set

Data to be transfered


Buffering Data

Dispatcher

SPOWP

BTCWP

DIAWP

SAPGUI

SAPGUI

SAPGUI

DBWPDBWPDBWP

Gateway

Program buffer

Screen bufferCUA buffer

DDIC buffersDDIC buffersDDIC buffersDDIC buffers

Object buffer

Calendar buffer

DDIC buffersDDIC buffersDDIC buffersTable buffers

SharedMemory

&Buffers


key1 key2 key3 data

key1 key2 key3 data

key1 key2 key3 data

key1 key2 key3 data

Resident Buffering(100%)

Generic buffering1 key field

Generic buffering2 key fields

Partial buffering(single record)

001001001001002002002002002002003003003003003003003003

001001001001002002002002002002002002003003003003003003003003003003003

001001001001001002002002002002002002002002002003003003003003003003003003003003003003

AA

BB

AABBBC

DC

AAABBCCCDDD

AA

BB

BAAAABBBC

DC

AAABBCCCCDDDD

42

31

513681230

53

2362423581234

Three Buffering Types

ÿ Full buffering is recommended for the following tables:

�Tables up to 30 KB in size. If a table is accessed frequently, but all accesses are read accesses,this value can be exceeded. However, you should always pay attention to the buffer utilizationfactor.

�Larger tables where large numbers of records are frequently accessed. However, if the applicationprogram is able to formulate an extremely selective WHERE condition for these multiple accessesusing a database index, it may be advisable to dispense with buffering.

�Tables where frequent attempts are made to access data not contained in the table (resulting in a"No record found" message). With full buffering, all records of a table are always contained in thebuffer, so that it is possible to decide directly whether or not the table contains a record for a specifickey.

ÿ Generic buffering is recommended especially for the following tables:

�Client-dependent, fully buffered tables are automatically buffered generically (even if full bufferingwas explicitly selected). The client field is the generic key. It is assumed that work is not beingcarried out in all clients simultaneously on an application server.

�Language-dependent tables are another example where generic buffering is reasonable. In general,only records of one language will be needed for an application server.

ÿ Single record Buffering

�Single-record buffering is recommended especially for large tables in which only a few records areaccessed. The size of the records being accessed should lie between 100 and 200 KB.


Table Buffers - Checklist

ÿ In a productive system rarely changed tables with

� Rather small size ('small' depends on access frequency)� Mostly read access� E.g. control tables, customizing tables, "small" master data

ÿ Check whether buffering allowed

� Not, if data must be always up-to-date (possible inconsistencywithin the synchronization period)

� Not, if overhead due to displacement and synchronization toohigh (> 1% changes)

ÿ For effective use of the buffer

� Choose the right buffering type� Avoid all kinds of bypassing statements� Avoid displacement / synchronization

ÿ The table buffer is filled:

�with the first reading (on demand)

�after changes from the ABAP

• on the same application server

• with synchronization time on other application servers after reading ten times


Technical Settings (SE13)

ÿ Is a table bufferable ? (logical decision)

ÿ If yes: buffering type (technical decision)

� Resident (100%)

� Generic (generic key) + number of fields in the generic key

� Partial (single record)

ÿ Special: Buffering allowed but off

� in customer system buffering can be switched on(installation-dependent)

� specification of buffering type is optional

ÿ Since 4.0 also for views and INDX-like tables (EXPORT TOSHARED BUFFER ...)

ÿ Tables buffered by record reside in the single-record table buffer TABLP, fully andgenerically buffered tables share the full/generic table buffer TABL.


Statements That Bypass the Buffer

ÿ SELECT ... BYPASSING BUFFER

ÿ SELECT ... FOR UPDATE

ÿ Any aggregate function (COUNT, MIN, MAX, SUM, AVG), GROUPBYSELECT MIN(F1) FROM T1 WHERE ...

ÿ SELECT DISTINCT ...

ÿ WHERE clause contains ... IS [NOT] NULL

ÿ ORDER BY (other than PRIMARY KEY)

ÿ Joins in Open SQL (SELECT ... JOIN ON ...)

ÿ Any EXEC SQL statement

ÿ In the case of single record buffering every statement where thekey is not fully specified (key word: SELECT SINGLE required)

ÿ In the case of generic buffering the generic key must be specified

ÿ With the SQL trace, you can check whether you actually read bypassing the buffer


Buffer Synchronization

1. Each change on a bufferable table is updated in the localbuffer and is noted in DDLOG table.

2. Synchronization takes one minute by default.

3. Each application server reads the DDLOG contents belongingto other application servers and marks the correspondingbuffer entries as invalid.

4. Changed data is not read from the database immediately butonly on demand.

ÿ If a buffered table is modified, it is updated synchronously in the buffer of theapplication server from which the change was made. The buffer synchronization forthe whole network, that is, the synchronization of the buffers of all the other applicationservers, is carried out using an asynchronous procedure.

ÿ Each application server reads the entries of the central database table (DDLOG)entries at fixed time intervals.

� If entries are found that show a change to the data buffered by this server, this data is invalidated. Ifthis data is accessed again, it is read directly from the database. In such an access, the table canthen be loaded to the buffer again.

�To prevent a table being constantly loaded to the buffer and then immediately invalidated there, thetable can only be loaded again to the buffer after a waiting time following invalidation.

ÿ The advantage of this method over a synchronous method (where the networkimmediately reports each change to buffered data of one server to all the otherservers) is that the load on the network is kept to a minimum.

ÿ The disadvantage of this method as compared with synchronous updating is that thedata will not be up-to-date during the time interval between two synchronizations. Forthis reason, only tables which have frequent read accesses and infrequent writeaccesses should be buffered.

ÿ Changes with EXEC SQL are NOT noted in DDLOG table


Granularity of Invalidation

ÿ Resident (100%) bufferable tables

� Any change invalidates the whole buffered table on all otherapplication servers and updates the local buffer

ÿ Generic bufferable tables

� Generic Key

� fully specified: Only the corresponding generic area ismarked as invalid on other application servers and updated inlocal buffer

� not fully specified: The entire table is marked as invalid onother application servers and updated in local buffer

ÿ Partially bufferable tables

� A change in the work area invalidates one buffered record

� Other changes invalidate the whole table


Buffer Monitoring

ST02 Tune Summary – Overview

ST02 Detail Analysis – Menu

SAP


Exercise 4

ÿ Analyse and optimize program with buffered tables(DSZ400_BYPASS_BUFFER)

ÿ Which tables read in this program

1. Are already buffered

2. Cannot be buffered

3. Are worth buffering


Agenda



Share(d) Memory


Parallelization



o


Exercise 5

ÿ Reading an ABAP internal table takes 0.01ms on average.

ÿ Your application needs to read 200 different configurationtables with a total size of 10MB.

ÿ How do you design your application assuming that hundredsof users will run your application in parallel?

1. Buffer all entries of the configuration tables in internal tables?

2. Use the table buffer?

3. Both?


Logical Memory Model on Application Server

SAP Instance (Application Server)

User Specific Memory

External Mode (Window 1)

Internal Mode

Application buffer across transaction (EXPORT/IMPORT/DELETE ... SHARED BUFFER)

SPA/GPA (SET/GET PARAMETER) memory or parameter memory (independent from mode)

ABAP-Memory (EXPORT/IMPORT)

...

ABAP-Memory

Main Program of TA/Report

FunctionGroup 1

FunctionGroup 2

External PERFORM

Main Program of calledTA/Report

FunctionGroup 3

FunctionGroup 1

External Mode 2


Logical Memory Model - Language Elements

SAP System

Database

SAP Instance (Application Server)

User Session

External Mode

Internal Mode

Application buffer across transaction (EXPORT/IMPORT/DELETE ... SHARED BUFFER)

SPA/GPA (SET/GET PARAMETER) memory or parameter memory

ABAP-Memory (EXPORT/IMPORT/FREE ... Memory

...

...

...

...

CALL TRANSACTION,CALL DIALOG,

SUBMIT ... AND RETURN

Open new Session

CALL FUNCTION ... DESTINATION 'NONE'

CALL FUNCTION ... DESTINATION


Memory Sizes

ApplicationServer

DialogWP 1

RollArea

Dispatcher

Rollout File (Buffer)

WPLocalMem.

Pages

Paging File (Buffer)

Extended Memory

1MB

Mapp.Area

DialogWP 2

RollArea

WPLocalMem.

Pages

Mapp.Area

1 GB

200 MB (64 MB)

200 MB (64 MB)

50 - 500 MB

6 MB

Up to 2 GB


Read Modules

Database (Disks)

DBMS

ApplicationServer

Table(s)

Consumers during one transaction

Database (Disks)

DBMS

ApplicationServer

Table(s)

Read Module InternalTable

VIEWs and ENQUEUEs

FG1 FG2 FG3 FG4 FG5 ... FG1 FG2 FG3 FG4 FG5 ...

Consumers during one transaction

ÿ Avoid multiple reading of data from the database during the transaction.

ÿ Avoid inconsistencies due to multiple reading of data.

ÿ The "owner" of this data should provide read modules which can be used by all otherconsumers.

ÿ Typically

�all master data

�material master

�business partner data

�address data


Read Modules and Internal Buffers

Database (Disks)

FG 1

DatabaseManagement

System

ApplicationServer

Table One Table Two

TableBuffer

HeaderLine

Read Module 2 InternalTable

VIEWs and ENQUEUEsTable header line

as"last read buffer"

Table isbuffered directly

on applicationserver

Table isbuffered inread module

Consumers

FG2 FG3 FG4 FG5 FG6 ...

ÿ Do not buffer a buffered table (additional memory consumption: table buffer plus usercontexts).

ÿ Customizing tables are suitable for table buffering, wheras master data tables arebetter off in a function module buffer.


Read Modules: Requirements

ÿ (Re-) read data protected by Enqueue bypassing internalbuffer

ÿ Mass processing must be possible

� REFRESH triggered by caller

� Default maximum size of internal buffer

ÿ Result "No Record Found" should be buffered, too

ÿ Buffer is loadable via PREFETCH technique

CALL FUNCTION 'MATERIAL_PREFETCH'tables itab.

LOOP AT ITAB ( )CALL FUNCTION 'MATERIAL_READ!

Exporting MATNR.ENDLOOP.


Check-Sequence for Buffering

Use of context possible?

Read module with internal buffering

Buffer in Table Buffer via technical settings1

2

3


Exercise 6

ÿ Implement a Read module with internal buffering for tableSCUSTOM


Agenda



Share(d) Memory


Parallelization


"Linear" Programmingo


xxx

mmn

n

nn

DDa

DaaT

log,

2

10

∗∗+

∗=

�

�+T

mnD ,

Linear extrapolation froma runtime measurementwith small amount of data

Linear extrapolation fromruntime measurementsvarying the amount of data

Internal Tables and "Linear" Programming

Runtime

1

3

2

Size of internal table

1 Linear extrapolation based on one measurement, for example order with two lineitems.

2 Linear extrapolation based on several measurements, for example orders with fourand six line items.

3 Predicted non-linear behavior even for optimal coding

� if you can, build small "packages".


Internal Tables

ÿ There are three ways of working with an internal table

� Address the whole table

� Address a range of entries

� Address an individual entry

ÿ The table type determines the efficiency of the access types


The type of table you should use depends on the operations thatwill be executed most frequently.

ÿ Hashed table

� For key access as main operation

� Fast and size-independent table access (for unique access)

� You cannot access a hashed table using its index

� Note: Range access results in complete LOOP AT TABLE

ÿ Sorted table

� For generic key access as main operation

� Easier coding than sorted Standard Table

� If you need a table which is sorted any time, particularly as youfill it

� Access costs grow by log n (n number of entries)

Types of Internal Tables I: Hashed and Sorted Table

ÿ Hashed table

�The response time for key access remains constant, regardless of the number of table entries. Likedatabase tables, hashed tables always have a unique key. Hashed tables are useful if you want toconstruct and use an internal table which resembles a database table.

ÿ Sorted table

�Entries are inserted according to the sort sequence defined through the table key. Any illegal entriesare recognized as soon as you try to add them to the table. The response time for key access islogarithmically proportional to the number of table entries, since the system always uses a binarysearch. Sorted tables are particularly useful for partially sequential processing in a LOOP if youspecify the beginning of the table key in the WHERE condition.

�LOOP ... AT WHERE ... Can be optimized for generic key accesses

� Index operations should be rare

� If the table does not have to be sorted during creation


Types of Internal Tables II: Standard Table

� For general purpose access

� Access type may change with time

� e.g. start: SORT itab BY KEY K1later: SORT itab BY KEY K2

� Size independent table access times for:

� READ itab INDEX

� APPEND itab

� COLLECT itab (itab built with COLLECT statement only)

� Access costs depending on

� log n for sorted Standard Table: READ itab WITH KEY BINARY SEARCH

� n log n: SORT itab BY KEY

� total number of entries: READ itab WITH KEY K1.LOOP AT itab WHERE ...LOOP AT itabl.

ÿ n = number of entries

ÿ Standard table

�The access time for a standard table increases in a linear relationship with the number of tableentries. If you need key access, standard tables are particularly useful if you can fill and process thetable in separate steps. For example, you could fill the table by appending entries, and then sort it. Ifyou use the binary search option with key access, the response time is logarithmically proportionalto the number of table entries.


Function co_ru_conf_postloop at caufd_tab CORF. perform det_conf_cost. Call function ck_f_actual_cost_calc (dyn) CK00. Perform co_object_co_ist_generate CK00. Call function ck_f_co_object_actual_generate CK10. Call function k_confirmation_check CK10. Perform fuellen COBK KABL. Perform append_cobk KABL. Append itcobk KABL. Call function k_confirmation_doc_check CK10. Perform rwin_check KABL. Loop at itcobk

KABL. . Loop at tkomp

KABL. . Call function g_cobk_header (dyn)

KABL. . Append itab GLIN. . Loop at itab where ... GLIN. . .

Internal Tables and "Linear" Programming


Internal tables - Allocation of Memory

ÿ Parameter OCCURS N may influence first size of memoryallocation

� with small tables : small N is useful

� with growing table N is of no importance

ÿ Nested tables allocate memory with each append

� overhead even for every empty table

ÿ Working with nested internal tables

� all underlying areas have to be copied to workarea for LOOP ATitab INTO w_itab

� better: Reference table entryLOOP AT itab ASSIGNING ... If possible


ABAP Contexts

ÿ Simplified and modular definition of complex computations

ÿ Buffering of complex computations on different levels

� Transaction level

� Session level

� Application server level


Exercise 7

ÿ Analyse and optimize program with nested loops(DSZ400_NESTED_LOOPS,DSZ400_NESTED_LOOPS_PARALLEL,DSZ400_NESTED_SORTED)


Agenda



Share(d) Memory


Parallelization



o


Exercise 8

ÿ An application program needs 100ms CPU time on thedatabase server and 1200ms CPU time on the applicationserver in average to create a product master.

ÿ How many parallel jobs do you need to create 1,000,000products in 10 hours?


Parallelization

ÿ Benefits of parallelization

ÿ Implementation

� Strategies of Parallelization

� Distribution of processes on several application servers

ÿ Possible Problems

� Locking

� Deadlocks

� Number of Processes

ÿ Using workload distribution in own programs


Sequential Work

WorkProcess 1

WorkProcess 3

WorkProcess 4

WorkProcess 2

WorkProcess 1

Only one work process is used while other processes are idle

WorkProcess 1WorkProcess 1







WorkProcess 1

ÿ Sequential (synchronous) processing of work packages means that one process isperforming all the work.

ÿ A work item must be fully processed before the processing of next one can be started.

ÿ Other processes that are ready to work are not used, available capacities are ignored.


Parallel Work

Many processes work at the same time

WorkProcess 1

WorkProcess 2

WorkProcess 3

WorkProcess 4

WorkProcess 1

WorkProcess 2

WorkProcess 3

WorkProcess 4

WorkProcess 1

WorkProcess 2

WorkProcess 3

WorkProcess 4

WorkProcess 1

WorkProcess 2

WorkProcess 3

WorkProcess 4

WorkProcess 1

WorkProcess 2

WorkProcess 3

WorkProcess 4

WorkProcess 1

WorkProcess 2

WorkProcess 3

WorkProcess 4

WorkProcess 1

WorkProcess 2

WorkProcess 3

WorkProcess 4

WorkProcess 1

WorkProcess 2

WorkProcess 3

WorkProcess 4

WorkProcess 1

WorkProcess 2

WorkProcess 3

WorkProcess 4

WorkProcess 1

WorkProcess 2

WorkProcess 1

WorkProcess 2

WorkProcess 3

WorkProcess 4

ÿ Parallel (asynchronous) processing means that the workload is distributed into severalpackages that are processed by several processes at the same time.

ÿ These processes are working independently.

ÿ All available capacities are used in order to achieve a minimal total processing time.


Parallelization


ÿ Implementation




� Locking

� Deadlocks




Workload Balancing (1)

T1 = Time until Completion

Goal: minimize T1

T1

time

waiting active

WP 5

WP 4

WP 3

WP 2

WP 1

14

17

10

18

9

75

19

1

86

42 3

12

1613

11

15

Static distribution beforehand according to e.g.numbers cannot consider the real workload

ÿ Distribution of work items according to formal attributes like numbers can cause anunbalanced workload: Work Items with extended processing time can increase thetotal time until completion of work.

ÿ Several work processes are not used for a rather long time.

ÿ Throughput (t) ~ Sum of active time until t.


Workload Balancing (2)

Dynamic distribution at runtime oriented to the real workload can leadto a better distribution and a higher throughput and thus reduces thetime until completion.

T1(before)

14

17

10 18

9

75

19

1

8

6

4

2

3 12

16

time

waiting active

WP 5

WP 4

WP 3

WP 2

WP 1

13

11 15

T1(now)

ÿ Distribution of work items oriented to the real processing time can achieve a betterworkload balancing. Small packages help to to achieve this goal.

ÿ All work processes are busy almost until completion of work � no hardware capacitiesare unused.

ÿ The time until completion of work (T1) is reduced.


BatchProcess 1

BatchProcess 2

BatchProcess 3

BatchProcess 4

BatchProcess 5

Load Distribution on Several Processes I

ÿ Start parallel processes manually

� Divide your work into several packages (e.g. by number intervals)beforehand

� Multiple start of a report with different parameters in Background or asBatch

ÿ The workload is divided by formal attributes beforehand

ÿ Some batch or background processes are started to process this data, so that thework can be scheduled at a time with minimal workload on the system.

ÿ It is still possible, that some packages take more time than other ones and cause adelay in the completion of the work.


DialogProcess 5

DialogProcess 4

DialogProcess 2

DialogProcess 3

Dialog/BatchProcess 1

Load Distribution on Several Processes II

ÿ Start one report that starts other processes with fixedpackages

� Hand over all work to a report

� The report divides it into suitable packages (e.g. same number ofIDOCs)

� Further processes are started with fixed packages

ÿ The complete data is handed over to a program that defines several work packages.The data can be examined in order to define packages with almost equal workload.These packages are distributed to other processes that are started by the originalprogram.


DialogProcess 5

DialogProcess 3

DialogProcess 4

DialogProcess 2

DialogProcess 1

“Distributor”

Load Distribution on Several Processes III

ÿ Dynamic Workload Distribution

� Hand over all work to a report

� The report starts other processes and distributes the work dynamically(next item after completion of a previous one)

ÿ All the data is handed over to a distributor program. It starts several other processeswith smaller packages of the data.

ÿ If a process has finished its work, the distributor restarts it with a new package.

ÿ The distributor must not process the data itself. Otherwise it might be busy and notready to hand over the next item when a process has finished its work.

ÿ This method of workload distribution has a good chance to achieve an (almost) equalload for all processes and no waste of system capacities.


How to parallelize

ÿ Schedule multiple batch jobs

� optimal for long-running, independent tasks

ÿ Use tRFCs

� useful for short, independent tasks that may run on othersystems

ÿ Use aRFCs

� useful for short tasks that must be synchronized

ÿ Use parallel query, parallel sort, ...

� Only useful for very special "administrative" tasks due todatabase dependencies


Parallelization


ÿ Implementation




� Locking

� Deadlocks




DON’T

Application Server 1 Application Server 2

Process

Process

Process

Process

Process

Process

Application Server 4

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process Process


Process

ÿ The application servers one to four belong to your specific application server group.There may be other application server groups in the system.

ÿ Don’t overload an application server by using all available work processes while otherservers have no work. All application servers should be used equally. In this casethere are no free work processes on the first Application server but all the otherservers are hardly used.

ÿ This is valid mainly for dialog work processes. You should always keep some freedialog work processes. You can use all batch processes in order to use the hardwarecapacities (other batch jobs will then be delayed, of course), but switch to otherservers before you have to wait in a queue.


DO


Process

Process

Process

Application Server 3 Application Server 4

Process


Process

Process

Process

Process Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process

Process


aRFC: Resource Determination

CALL FUNCTION ...DESTINATION IN GROUP ...STARTING NEW TASK 'ABC'

Group B

WP1

WP3

WP2

...

Message-Server

Instance 1

Dispatcher-Queue

WP1

WP3

WP2

...

Instance 2

Dispatcher-Queue

Usequotas?

yes

ÿ There are several quotas that define if a server can be used for a RFC:

�Number of free dialog work processes

�Percentage of user-related dialog work processes

�Percentage of ongoing requests in the dialog queue

�Percentage of logons to the system

�Percentage of your own logons in the system

�Percentage of used communication entries.


Parallelization


ÿ Implementation




� Locking

� Deadlocks




Processing data in a non-sorted sequence can create deadlocks.

Deadlocks (1)

WorkProcess 2

216 9 10

45 3 13

WorkProcess 1

41 8 12

316 7 11

Database Table

5

3

2

4

6

7

8

13

11

10

12

14

15

16

19

DEADLOCK !Process 1 must wait forRelease of the Lock byProcess 2

Process 2 must wait forRelease of the Lock byProcess 1

ÿ Sometimes, a database can recognize a deadlock like this and solve the problem byrolling back one of the processes. But if the deadlock is caused by a more complexsituation, there is no automatic solution.

ÿ There is no problem, if the same work process within a transaction accesses a recordthat is already locked by itself. But if this access is performed by another work process(started e.g. by RFC) in this transaction the transaction blocks itself.


ÿ Processing data in the same sorted sequence avoids deadlocks.

Deadlocks (2)

WorkProcess 2

42 3 5

139 10 16

WorkProcess 1

41 3 7

128 11 16

Database Table

Process 2 must wait forRelease of the lock byProcess 1

All records are processed�� COMMIT WORK

NO DEADLOCK

5

3

2

4

6

7

1

8

13

11

10

12

14

15

9

16

The lock is released.Process 2 can continue

ÿ If the data is processed in the same sorted sequence (e.g. ascending key) it is stillpossible, that work processes 2 is blocked by a lock from work process 1. But in thiscase, all records that are locked by work process 2 so far, do not need to be accessedby work process 1. A deadlock is not possible.


ÿ Too many processes

� If there are too many active processes in the system, they will blockeach other due to resource problems. This will increase the processingtime and reduce the throughput.

� Use about 1.5 Processes per CPU on a pure Application-Server andonly 1 Process per CPU on a Server with Database.

Number of Processes

Throughput

No of Parallel processes

optimal

ÿ There is a point when an additional process increases the throughput only marginally.You should not add more processes, because the throughput can flatten out.


Parallelization


ÿ Implementation




� Locking

� Deadlocks




Hints for Designing Your Own Programs

Use the same sorted sequences for the processingof data in the whole system to avoid deadlocks

Take care to balance workload

Be careful with locks

Design your program for parallel workEven if it is not yet necessary - the day might come

1

Tool in Reuse Library available

2

3

4

5

ÿ Pay attention to release system resources and refresh internal tables to delete oldinformation.

ÿ Keep the locking time as short as possible especially for central objects of the system.


Multi-User System Analysis and Optimization

SM66, SM50 Work process overview

ST04, DB02 Database monitor

ST06 Operating system monitor

ST02 Buffer and memory monitor

ST07 Application monitor

SM56, SNRO Number ranges

ST03 Statistic records

Available Monitoring Tools


Agenda



Share(d) Memory


Parallelization



o


Exercise 9

ÿ How long is the minimum response time in a satellite connectionwhen the application needs 30 communication steps per screenchange?


Communication to Database

ÿ Use the ARRAY Interface if possible

� INSERT/UPDATE/DELETE FROM TABLE

� SELECT ... ENDSELECT or SELECT ... INTO TABLE

ÿ Use buffers

ÿ Use a "read on request" instead a "read in advance"programming model

Table

Buffers

Dispatcher

SPOWP

BTCWP

DIAWP

Table

Buffers

Dispatcher

DIAWP

ENQWP

EnqueueTable

SAPGUI

SAPGUI

SAPGUI

SAPGUI

SAPGUI

DBWPDBWPDBWP DBWP

GatewayGateway



Communication to Frontend

ÿ Make reasonable use of the SAPGUI_PROGRESS_INDICATOR

ÿ Do not synchronize the contents of controls to often (explizitflush)

ÿ Limit the amount of data sent to the frontend

Table

Buffers

Dispatcher

SPOWP

BTCWP

DIAWP

Table

Buffers

Dispatcher

DIAWP

ENQWP

EnqueueTable

SAPGUI

SAPGUI

SAPGUI

SAPGUI

SAPGUI

DBWPDBWPDBWP DBWP

GatewayGateway



Communication between application servers

ÿ Optimize the number of RFCs

ÿ Use RFC connections as long as possible

Table

Buffers

Dispatcher

SPOWP

BTCWP

DIAWP

Table

Buffers

Dispatcher

DIAWP

ENQWP

EnqueueTable

SAPGUI

SAPGUI

SAPGUI

SAPGUI

SAPGUI

DBWPDBWPDBWP DBWP

GatewayGateway



Exercise 10

ÿ Determine the time for a round trip to your presentationserver

� (Note: Use function "SAPGUI_PROGRESS_INDICATOR andlanguage element "GET RUN TIME ")


Guarantee Scalability and Performance of

ÿ Make optimal use of SAP's multi-tier client-serverarchitecture

� Database, buffers, network traffic, memory management, ...

ÿ Find balance between functionality and resourceconsumption

ÿ Avoid implicit platform (database) dependencies

ÿ Create robust multi-user applications for high concurrency

ÿ Exploit the latest database and SAP basis technologies


Summary

ÿ Scalability is ensured by relying on the big picture

� Avoiding locks

� Optimizing DB accesses

� Optimizing memory consumption

� "Linear" programming

� Parallelizing

� Ensuring optimal communication

ÿ Detailed information on optimizing SQL statements

� Ulrich Koch's workshop

ÿ Detailed information on internal tables

� Rolf Hammer's workshop


Solutions to Exercise No. 1

ÿ The exclusive look is held for 100ms

ÿ The system can process 10 documents per second

ÿ The total processing time is at least 10,000 seconds or 2h46min 40s

� No matter how many CPUs the database server has

ÿ If ordering by time is not required, parallelization is possible



ÿ Read from database in best case 1ms

ÿ Read from buffer 0,1ms

ÿ 200 reads from database: 200 * 1ms = 200ms

ÿ 180 reads from buffer + 20 reads from database: 180 * 0,1ms +20 * 1ms = 38ms

ÿ New run time: 1,000ms - 162ms = 838ms ( 83,8%), or 16,2%reduction

ÿ The maximum throughput achievable on a given databaseserver is increased by a factor of 200/20 = 10.



ÿ If all configuration tables would be loaded into ABAP internaltables

� Each user session with this transaction would at least need 10MB

ÿ Hundreds of sessions would result in more than 1GB physicalRAM needed to have good performance and have all internaltables simultaneously in physical memory

� Because only then the 0.01 ms average access time would betrue

ÿ Therefore usually the table buffer is used



ÿ 10h = 36,000s

ÿ 1,000,000 / 360,000 = 2,77

ÿ You need 3 CPUs on the database server and 2.77 * 12 = 34CPUs for the application server.

ÿ To make optimal use of the system, you have to parallelize atleast 34 fold



ÿ For a satellite communication with acknowledgement thedistance is at list 4 * 36000km.

ÿ Due to the speed of light (300,000km/s) this results in about0.5 s per roundtrip.

ÿ 30 round trips add up to 15 s


Copyright 2000 SAP AG (All rights reserved)

ÿ Some software products marketed by SAP AG and its distributors contain proprietarysoftware components of other software vendors.

ÿ Microsoft ®, WINDOWS®, NT®, EXCEL®, Word ® and SQL-Server ® are registered trademarks ofMicrosoft Corporation.

ÿ IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex ®, MVS/ESA®, RS/6000®, AIX®, S/390®,AS/400®, OS/390®, and OS/400 ® are registered trademarks of IBM Corporation.

ÿ OSF/Motif ® is a registered trademark of Open Software Foundation.

ÿ ORACLE ® is a registered trademark of ORACLE Corporation, California, USA.

ÿ INFORMIX®-OnLine for SAP is a registered trademark of Informix Software Incorporated.

ÿ UNIX®, X/Open ®, OSF/1®, and Motif ® are registered trademarks of The Open Group.

ÿ SAPDB ® is a registered trademark of SAP AG.

ÿ SAP, SAP-Logo, mySAP.com, R/2, R/3, RIVA, ABAP, SAP-EDI, SAP Business Workflow, SAPEarlyWatch, SAP ArchiveLink, ALE/WEB, BAPI, SAPPHIRE, Management Cockpit, SEM, aretrademarks or registered trademarks of SAP AG in Germany and in several other countriesall over the world. All other products mentioned are trademarks or registered trademarks oftheir respective companies.

Date post:	17-Feb-2016
Category:	Documents
Upload:	rajesh
View:	31 times
Download:	0 times

Performance Analysis Tuning

Documents