Download - Performanance Issue Imp Sap Abap
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 1
Performance Analysis in a Nutshell
Dr. Ulrich Marquard
Performance, Data Management & Scalability SAP AG
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 2
Learning Objectives
As a result of this workshop, you will be able to:
Ensure that your programs adhere to the most basic rules of scalabilityAnalyze coding for performanceKeep resource consumption of your programs within reasonable limitsOptimally use the central resources in a systemEnable optimal server-to-server communication
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 2
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 3
Agenda
Goal of Client Server Programming: Scalability
A little bit of theory and tips and tricksAppropriate indexesUse SAP BuffersNo identical accesses to persistence layerComplete WHERE clausesEnabling parallel processingLinear dependency Two round trips per user interaction
Summary
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 4
Goal of Client Server Programming: Scalability
Small systemone userone server
Thousands of users
Terabytes of data
High throughput
Large objects
7*24h operation
High concurrency
Connected users
worldwide
Many servers
scalabilityScalability
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 3
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 5
Multi-Tier Architecture – Optimization Potential
Presentation
Application
Database
Internet
Layer
10-20%
60-70%
5-10%
10-20%
Load
Memory & CPU Consumption
Memory & CPU Consumption
Memory & CPU Consumption
Memory & CPU ConsumptionPhysical I/O
Controls
Compression Templates
Process DesignApplications, Customizing
OS
What? Where?Optimization Potential
Network Communication
Network Communication
Network Communication
Techn. InfrastructureDB
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 6
Architecture of mySAP Solutions
DBWP DBMS
Database
SQL Trace
SharedMemory
andBuffers
Dispatcher
WP ENQWP
EnqueueTable
SAPGUI
Gateway
SAPGUI
WebServer
Browser
ITS
WP
Dispatcher
SE30BufferTrace
EnqueueTrace
RFC Trace
Browser
ICMAN
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 4
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 7
The Architecture of mySAP Solutions
DBWP DBMS
Database
SQL Trace
SharedMemory
andBuffers
Dispatcher
WPENQWP
EnqueueTable
SAPGUI
Gateway
SAPGUI
WP
Dispatcher
SE30Buffer Trace
Enqueue Trace
RFC Trace
Browser
Approx. 2.6KB
20KB
10MB
100 MB
10 GB
10GB – 2 TB
0.1ms
1ms
10ms
10ms
0.01ms
WebServer
ITS
Browser
ICMAN
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 8
Agenda
Goal of Client Server Programming: Scalability
A little bit of theory and tips and tricksAppropriate indexes
How to keep the number of searched records small
Use buffers and cachesNo identical accesses to persistence layer (DB) within one transactionComplete WHERE clausesEnable parallel processingLinear dependency Two round trips per user interaction step
Summary
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 5
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 9
Theory: Layout of Tables and Indexes
TableIndex A
Block 2
Block 3
Block 1
4
5
123
6
7
Record 4
Record 2
Record 5Record 1Record 6
Record 7
Record 3
Index B
217
4
5
3
6
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 10
Using Indexes to Limit the Hit List I
Create primary index key1, key2, key3Index is sorted in the order specified at creation
select * from table where key1 = 002 and key2 = A and key3 = 3
key1 key2 key3 data001001001001001002002002002002002002002002002003003003003003003003003003003003003003
AA
BB
BAAAABBBC
DC
AAABBCCCCDDDD
42
31
513681230
53
2362423581234
002 A 3
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 6
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 11
Using Indexes to Limit the Hit List II
Create primary index key1, key2, key3Index is sorted in the order specified at creation
select * where key1 = 002 and key2 = A
key1 key2 key3 data001001001001001002002002002002002002002002002003003003003003003003003003003003003003
AA
BB
BAAAABBBC
DC
AAABBCCCCDDDD
42
31
513681230
53
2362423581234
002002002002
AAAA
1368
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 12
Using Indexes to Limit the Hit List III
Create primary index key1, key2, key3Index is sorted in the order specified at creation
select * from table where key1 = 002 and key3 = 3 (range scan for key2)
select * from table where key1 = 002 and key2 BETWEEN A and D and key3 = 3)
key1 key2 key3 data001001001001001002002002002002002002002002002003003003003003003003003003003003003003
AA
BB
BAAAABBBC
DC
AAABBCCCCDDDD
42
31
513681230
53
2362423581234
002002002002002002002002002002
AAAABBBC
DC
13681230
53
Exercise 1
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 7
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 13
Logon Information
System name: Dev
Server: iwdf9260.wdf.sap.corp
Router: sapgate.wdf.sap.corp
Sytem number: 00
SAP user: BC490-xx (xx team number)
Passwd: init
Client: 900
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 14
Exercise 1: Where Can an Index be Used?
A table has the following columns: NAME, FIRST NAME, CITY, CITY CODE, and STREET
A secondary index has been created with the structure NAME, CITY, STREET
In the table, the columns and operators for the WHERE clauses are given
Example: SELECT ... WHERE NAME = ' ...' and STREET = '..'
To what extent can an index be used for each statement?
NAME CITY STREET Comment1 = =2 = =3 = =4 = IN =5 = BETWEEN =6 = LIKE =7 = IN IN8 = < > =
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 8
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 15
Exercise 1
Exercise 1AOn the previous slide there is a table for which a secondary index is defined. The primary index for this table is not needed for this exercise. Using the columns of the index and the column operators, determine how the database processes the different queries.
Exercise 1B Create an ABAP report program to confirm your results from 1 A. Copy the sample program ZDS400_DB_EXERCISE1_TEMPLATE and name it ZDS400_DB_EXERCISE1_##. ## is your group number. Program the eight different operators according to the information provided. Use transaction ST05 to analyze the eight different SELECTs. Then use the database explain to determine the access path. The NAMEcolumn in the theoretical part of the exercise corresponds to the LNAMEcolumn in the hands-on exercise. As transaction ST05 is activated for the entire server, before activating the trace make sure that another user has not already started the trace.
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 16
Design Rules: Table Design vs. Index DesignKeep the Area to Be Searched Small
All frequently executed statements (selects, updates and deletes) on large tables must be supported by indexes
A highly modified table should not have too many indexes. The more columns an index has, the higher the chance that an update will affect one of the indexed columns
Columns frequently specified with ‘=‘ should be at the beginning of the index
Most selective columns firstNot selective: bukrs
Highly selective: belnr, matnr, kunnr, objnr (to bring the optimizer as soon as possible to the right index)
MANDT - as an exception - should still be part of every index at the first position
A proper index design ensures that the search time is nearly independent of the number of table rows
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 9
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 17
Agenda
Goal of Client Server Programming: Scalability
A little bit of theory and tips and tricksAppropriate indexesUse buffers and caches
How to read data and make them available for other programs
No identical accesses to persistence layerComplete WHERE clausesEnable parallel processingLinear dependency Two round trips per user interaction step
Summary
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 18
Program Buffer
Screen BufferCUA Buffer
DDIC buffersDDIC buffersDDIC buffersNametab Buffers
Export/Import
Calendar Buffer
DDIC buffersDDIC buffersDDIC buffersTable Buffers
Buffering Data
OTR Buffer
Export/Import SHM
DBWP DBMS
Database
SQL Trace
SharedMemory
andBuffers
Dispatcher
WPENQWP
SAPGUI
SAPGUI
SE30Buffer Trace
Enqueue Trace
Browser
WebServer
ITS
Browser
ICMAN
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 10
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 19
Screenshot of Transaction ST02
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 20
Buffered Objects – Detail Screen
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 11
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 21
Buffer Types
Single Record Buffer
key1 key2 key3 data001001001001001002002002002002002002002002002003003003003003003003003003003003003003
AA
BB
BAAAABBBC
DC
AAABBCCCCDDDD
42
31
513681230
53
2362423581234
key1 key2 key3 data
key1 key2 key3 data
Fully Buffering(100%)
Generic Buffering1 Key Field
Generic Buffering2 Key Fields
001001001001002002002002002002003003003003003003003003
key1 key2 key3 data001001001001002002002002002002002002003003003003003003003003003003003
AA
BB
AABBBC
DC
AAABBCCCDDD
Generic Buffers
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 22
Screenshot of Transaction SE13
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 12
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 23
Table Buffers – Checklist
In a production system, the following tables may be considered for buffering
Small tablesTables that are mainly accessed for readingFor example, control tables, Customizing tables, or 'small' master data tables
Check whether buffering allowedNo, if data must always be up-to-date (possible inconsistency within the synchronization period)No, if overhead due to displacement and synchronization is too high (> 1% changes)
For effective use of the bufferChoose the right buffering typeBe aware that not all statements can make use of the bufferAvoid displacement or synchronization
Some statements may bypass the buffers
Consider granularity of invalidation
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 24
Statements that Bypass the Buffer
SELECT ... BYPASSING BUFFER
SELECT ... FOR UPDATE
Any aggregate function (COUNT, MIN, MAX, SUM, AVG), GROUP BYSELECT 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 native SQL statement
For single-record buffering, every statement where the key is not fully specified (key word: SELECT SINGLE required)
For generic buffering, the generic key must be specified
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 13
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 25
Granularity of Invalidation
Resident (100%) Bufferable TablesAny change invalidates the entire buffered table on all other application servers and updates the local buffer
Generic Bufferable TablesGeneric Key
Fully specified: Only the corresponding generic area is marked as invalid on other application servers and updated in the local bufferNot fully specified: The entire table is marked as invalid on other application servers and updated in the local buffer
Single Record Bufferable TablesA change in the work area invalidates one buffered recordOther changes invalidate the whole table
Bufferable ViewsInvalidated whenever a base table is changedAlways completely invalidatedSynchronization with transport layer supported since SAP R/3 Release 4.6C
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 26
Exercise 2 on Buffering
Exercise 2Would you buffer the table that contains the currency conversiondata?Would you buffer the table that contains the material stock information?
For both questions 1. Reflect on the pros and cons with your partner 2. Check the settings of tables TCURR and MARD in the SAP System
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 14
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 27
Agenda
Goal of Client Server Programming: Scalability
A little bit of theory and tips and tricksAppropriate indexesUse buffers and cachesNo identical accesses to persistence layer
How to avoid several accesses to the same data within one transaction
Complete WHERE clausesEnable parallel processingLinear dependency Two round trips per user interaction step
Summary
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 28
...FG1 FG2 FG3 FG4 FG5Consumers during one transaction
Read Modules = Buffers in Application Program
Database (Disks)
DBMS
Application Server
Table(s)
Database (Disks)
DBMS
Application Server
Table(s)
Buffer (Table Buffer and Read Modules)
...FG1 FG2 FG3 FG4 FG5Consumers during one transaction
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 15
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 29
Read Modules = ABAP Buffers
Read modules are special function groups or classes that store information read from the database in global internal tables.
The visibility of the data is restricted to one SAP Logical Unit of Work (LUW)
Read modules should be used:When buffering the information using the technical settings of the table is not feasibleTo prevent unnecessary database calls when the same data record is used in different program units of the transactionTo ensure consistent data within one transaction
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 30
Requirements for Read Modules
Read Modules mustSupport different access types to the data to
Allow flexible useSupport a prefetch technique
Be designed to operate well in long-running transactions and programs; the size of the buffer needs to be controllable, both internally and externallyBuffer: No Record FoundWork both for dirty read and selects protected by an enqueue.
To check for identical SELECT statementsUse transaction ST05Statement Summary
Second column "No. Of identical selects in percent
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 16
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 31
Exercise 3 on Read Modules
What is the use of writing a read module with buffering for the table TCURR?
Discuss the pros and cons with your partner in view of exercise 2
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 32
Agenda
Goal of Client Server Programming: Scalability
A little bit of theory and tips and tricksAppropriate indexesUse buffers and cachesNo identical accesses to persistence layerComplete WHERE clauses
How to keep the number of transferred data records small
Enable parallel processingLinear dependency Two round trips per user interaction step
Summary
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 17
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 33
Keep the Amount of Transferred Data Small
Read only needed rows of a table
Use WHERE clauses to filter dataDon't use CHECK statements
To check the number of selected recordsUse transaction ST05 Statement SummarySort column "Records"
Also possibleUse field listsUse aggregate functions
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 34
Use WHERE Clauses Whenever Possible
SELECT * FROM tableWHERE field1 = '001’ AND field2 >= 'ABC'.
... do something ...ENDSELECT.
SELECT * FROM table.CHECK field1 = '001'.CHECK field2 >= 'ABC'.... do something...
ENDSELECT.
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 18
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 35
Use Projection Views and Field Lists
Use projection views defined in ABAP Dictionary
Use field list (SELECT clause)
Reduce Amount of Data Transferred
Exercise 4
SELECT column1 column2 INTO (f1, f2) FROM table WHERE condition.
... do something ...
ENDSELECT.
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 36
Exercise 4: Automatic Use of DB Array Interfaces
Copy the sample ABAP report program DS400_DB_EXERCISE2_TEMPLATE to ZDS400_DB_EXERCISE2_##,where ## is your group number.
Program two selects of the ZDS400_TAB1 table, one using SELECT/ENDSELECT and one using SELECT INTO TABLE.
Use transaction ST05 to see what the differences are.
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 19
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 37
Use Aggregate Functions - COUNT, SUM, MAX, MIN, AVG
SELECT SUM( amount ) INTO sum FROM tab WHERE year = '1996'.
sum = 0.SELECT amount INTO amt FROM tab WHERE year = '1996'.
sum = sum + amt. ENDSELECT.
Note: Aggregate functions bypass the buffer
Reduce Amount of Data Transferred
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 38
Use Aggregate Functions - GROUP BY/HAVING
SELECT year SUM( amount ) INTO (y, sum) FROM tableWHERE company = '0001'GROUP BY year.... do something ...
ENDSELECT.
SELECT year SUM( amount ) INTO (y, sum) FROM tableWHERE company = '0001'GROUP BY yearHAVING sum( amount ) > 1000000.... do something ...
ENDSELECT.
Reduce Amount of Data Transferred
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 20
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 39
Use Aggregate Functions - Problems
Database may round differently than ABAP Dictionary
Databases can handle null values - ABAP does notAVG (1, 3, null, null) = 2 DBAVG (1, 3, 0, 0) = 1 ABAP
Choose the correct type for the target columnFor AVG, use a floating point typeFor SUM, use a type larger than the original to handle overflows
Reduce Amount of Data Transferred
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 40
Use Aggregate Functions to Update
Use UPDATE SET when possible:
UPDATE tab SET f3 = f3 + c “sometimes no SELECTWHERE f1 = A and f2 = B. “necessary
SELECT * from tab WHERE f1 = A and f2 = B.ADD c TO tab-f3. UPDATE tab. “every index must be maintained
ENDSELECT. “rollback/redo is written for all columns
Also possible:UPDATE tab SET tab~f3 = tab~f3 + tab~f4
WHERE f1 = A and f2 = B.
Reduce Amount of Data Transferred
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 21
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 41
Agenda
Goal of Client Server Programming: Scalability
A little bit of theory and tips and tricksAppropriate indexesUse buffers and cachesNo identical accesses to persistence layerComplete WHERE clausesEnable parallel processing
How to make proper use of database locks and SAP enqueues
Linear dependency Two round trips per user interaction step
Summary
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 42
Workload Balancing
idle
idle
idle
Parallel processing (optimal load distribution)
Sequential processing
Parallel processing (not optimized load distribution)
time
WP1
WP4WP3WP2WP1
WP4
WP3WP2
WP1
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 22
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 43
Parallel Processing in a Process Chain
A balanced load distribution is especially important for processes in a process chain.
Each step must be finished completely before starting the next one.
Reduce processing time of each single step to reduce the processing time of the whole chain ( total time ≈ t1 + t2 + t3 + t4)
Do not waste time or leave resources unused
t2 t3 t4
time
t1
active
active
active
active
idle
idle
idle
POS Upload Replenishment Deliveries Transfer Orders
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 44
Load Distribution on Several Processes: Static Approach
Start and define parallel processes manuallyDivide your work completely into several fixed packages (e.g. bynumber intervals or site groups) beforehandStart several sessions of the same report as batch jobs, each with different parameters
Batch Process 1
Batch Process 2
Batch Process 3
Batch Process 4
Batch Process 5
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 23
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 45
Run one report that starts other processes with fixed packagesHand over all the work to one report The report divides it completely into suitable packages (e.g. same number of IDOCs)Further processes are started with fixed packages
Load Distribution on Several Processes: Improved Static Approach
Dialog/Batch Process 1
Dialog/Batch Process 2
Dialog/Batch Process 3
Dialog/Batch Process 4
Dialog/Batch Process 5
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 46
Load Distribution on Several Processes: Dynamic Approach
Dynamic Workload DistributionHand over all work to a report The report starts other processes and distributes the work in small packages dynamically (next item after completion of previous)
Dialog Process 5
Dialog Process 1
Dialog Process 2
Dialog Process 3
Dialog Process 4
"Distributor"
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 24
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 47
How to parallelize
Schedule multiple batch jobsOptimal for long-running, independent tasks
Use tRFCs Useful for short, independent tasks that may run on other systems
Use aRFCsUseful for short tasks that must be synchronized
Use parallel query, parallel sort, ...Only useful for very specific "administrative" tasks due to database dependencies
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 48
Locking Problems
Processes can block each other by enqueue locks, semaphore locks or (as in this graphic) a database lock.
Time
WP1
WP2
WP3
Update record 1 Commit
Update record 1 Commit
Update record 1 Commit
Wait time
Wait time
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 25
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 49
Exercise 5: On Parallelization
Assume, the processing time for an elementary task is 1 second, including a minimum locking time of 0.5 seconds
How many parallel processes achieve optimal throughput?
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 50
Agenda
Goal of Client Server Programming: Scalability
A little bit of theory and tips and tricksAppropriate indexesUse buffers and cachesNo identical accesses to persistence layerComplete WHERE clausesEnable parallel processingLinear dependency
How to make optimal use of internal tablesTwo round trips per user interaction step
Summary
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 26
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 51
Internal Tables and “Linear” Programming
Linear extrapolation from small arrays
Size of internal tables n, m
Non-linear behavior for large tables
Linear extrapolation from small non-array processing
xxx
100 10.00010
T
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 52
Using Internal Tables
Avoid too large internal tablesFor example, process you data in packages instead of one large chunk
Choose the right internal table type
To check the size of internal tablesUse transaction SE30, Runtime AnalysisUse special screens in the ABAP Debugger11
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 27
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 53
Overview: Table Types
most flexibletype
Remark
must be unique
unique ornon unique
non uniqueKey
only by keyby keyby indexMain Access Type
for single linesfor key rangesvariableMain Access Range
HashedSortedStandard
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 54
Review: Accessing Internal Tables
Work area versus header lineTry to avoid header lines, they can cause errors
TRANSPORTINGREAD TABLE works with TRANSPORTING fieldlist and ‘NO FIELDS’LOOP AT ITAB does not work with TRANSPORTING fieldlistUse fieldlist if amount of transported data is reduced considerably Use TRANPORTING NO FIELDS if only SY-INDEX or SY-SUBRC is needed
ASSIGNING (from SAP R/3 4.5)Direct table access without copying to work areaAlso no MODIFY necessary
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 28
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 55
Runtimes for Table Accesses
Slowest table access are sequential and grow linearly with n READ standard table with (table) key (no BINARY SEARCH)LOOP at table where READ hashed table with key (not table key)
Faster access use a sorted index and have a weak dependence on nREAD standard table with key with BINARY SEARCH (must be sorted)READ sorted table with table key
Fastest accesses are independent of nREAD hashed table with table keyREAD standard table with indexREAD sorted table with index
Note: n = number of lines in itabExercise 6
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 56
Program: ZDS400_ABAP_EX_1Task: Runtimes for different table accesses should be measured. Your task: Start the program from SE38, then you can select up to 6 out of the following 9 access types which can be measured in parallel:
Note, on a standard table the READ standard table WITH TABLE KEYdoes not use binary search, but the READ standard table WITH KEYBINARY SEARCH (table must be sorted).Note, 3-1 does not make sense, as a hashed table has no index.
Exercise 6: Reading Internal Tables I
Read with Key
Read with Index
Standard Table
1-1
Sorted Table
2-1
3-1
Read with Table Key
1-2 1-3
2-2 2-3
3-2 3-3Hashed Table
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 29
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 57
Exercise 6: Reading Internal Tables II
Further parameters
The number of lines of the table is determined by N, with N = N_init + N_inc * N_i and N_i = 1,... N_loops
For better statistics the whole procedure can be repeated S_loops times
The detail level of the result can be determined by detail parameters detail_1, detail_2 and detail_3:
If detail_1 is active, then the runtimes for individual reads are shown. This allows to check whether runtime of the read depends on the address of the read, i.e. whether it is shorter if the wanted entry is at the beginning of the table and longer if it is at the end (that is true with sequential reads). Ten reads to equidistant locations are programmed.If detail_2 is active, then the average over these 10 reads is shown.If detail_3 is active, then the overall-average 10 * s_loops is shown.
Start the program with the default parameters and increase the table size
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 58
Runtimes for Table Accesses (Scaling)
O(1) Read with Generic
Key => O(n)!
after Sorting Read with Key
BINARY SEARCH
Remarks
O(1)O(log n)O(n)Read with Key
impossibleO(1)O(1)Read Index
HashedSortedStandard
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 30
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 59
Review: Filling Internal Tables
Internal tables can be filled
From DB tables Best with array fetch INTO TABLE or APPENDING TABLEIf possible, try to use identical line types, as the command INTO CORRESPONDING FIELDS signifies an overhead for accesses to buffered tables
From other internal tablesBest with array fetch APPEND LINES OF or INSERT LINES OFBeware that MOVE-CORRESPONDING works only on the work area
With COLLECT lines with identical key are aggregated to one line, all numeric fields are summed up automatically
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 60
Runtimes for Filling Tables
APPENDOnly for standard table: independent of n
INSERT : Standard table: ~ n Location (Index) must be determined with READ. Use BINARY SEARCH as insert is only useful on sorted standard tables. Becomes faster for n > 4096 when a B* index is used.Sorted table: ~ log n Direct INSERT with similar cost as above. Rearrangement is lessexpensive as a B* index is usedHashed table: ~ independent of n Finding location is cheap. Rearrangement of the hashed function also.
B* index: see index on database
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 31
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 61
Internal Tables: Performance Checklist
Use the right table type:Standard table for multiple access types, use BINARY SEARCH for mass accesses and try to SORT only onceSorted table, if generic key access is main access typeHashed table if single line access with fully specified key is only access type
Fill table efficientlyuse array operations and APPEND or INSERT
Use TRANSPORTING fieldlist / NO FIELDS if useful
Use ASSIGNING especially in nested tables
Try to keep internal tables small
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 62
Hashed Tables Versus Sorted Tables
Hashed tables can only be used if main access uses full table keyGeneric accesses are very slow Best example: Key contains a GUID
Which single line access is faster ?The scaling of hashed-tables is better However, access costs are similar to sorted tables for sizes up to 100There is a slight advantage for hashed tables for very large tables
However, keep in mind:That internal tables should generally not become too largeMost large tables are large because operations work on generic key ranges and not only on single lines
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 32
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 63
Sorted Standard Table Versus Sorted Table
Sorted Standard TableAccess with binary search as good as access on sorted tableMost flexible table
Different access types can be supportedFastest filling method:
If it is not necessary that the table is always sorted during fillingUse APPEND , ... , APPEND and one SORT at the endA small number of additions should use INSERT instead of APPEND
Sort is expensive as O(n log n).Every unnecessary extra sort should be avoidedNote: The most expensive SORT is the one on an already sorted table
Sorted tables Are much more convenient if a specific order must be always guaranteed
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 64
Agenda
Goal of Client Server Programming: Scalability
A little bit of theory and tips and tricksAppropriate indexesUse buffers and cachesNo identical accesses to persistence layerComplete WHERE clausesEnable parallel processingLinear dependency Two round trips per user interaction step
How to use controls efficiently
Summary
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 33
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 65
SAP GUI Interaction Model - Controls
Control Framework
Automation Controller
Frontend
Backend
Automation HandlingJava OLE
ABAP ProgramCALL METHOD1.CALL METHOD2.
RFC
ActiveXControl
Application Server
SAP GUI Client
Automatic Flush
Automation Queue
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 66
Controls – Round Trips in a WAN
Improve Performance by Minimizing Round Trips
Particularly important in a WAN environment (high latency times)
Latency times in a WAN environment approx. 0.3 seconds
For satellite connections approx. 0.5 seconds
Increasing bandwidth does not improve round-trip performance
Take WAN users into account by querying the Low Speed Connectionindicator that can be set in SAP GUI
Provide the user an ability to reduce the amount of data, such as by providing an option to only display part of a document
Avoid unnecessary calls of SAPGUI_PROGRESS_INDICATOR
The same arguments hold for RFC communication between applications
Use bulk processing instead of single processing
Reuse existing connections whenever possible
Exercise 7
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 34
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 67
Exercise 7: Measure Roundtrip Times
Call transaction Performance Trace (ST05). Activate the SQL trace and RFC trace.
Execute program ZDS400_CONTROLS_ALVGRID:With SE38, count the round trips and the runtime of the round tripsFrom SE80, count the round trips and the runtime of the round trips. Why do you see more round trips in the trace ?
Find out who triggers the flushes. Use the debugger and set an breakpoint in function module ‘AC_FLUSH_CALL’.
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 68
Agenda
Goal of Client Server Programming: Scalability
A little bit of theory and tips and tricksAppropriate indexesUse SAP BuffersNo identical accesses to persistence layerComplete WHERE clausesEnabling parallel processingLinear dependency Two round trips per user interaction
Summary
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 35
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 69
Summary: A Checklist for Scalable Client-Server Programs
Checklist for Adherence to General Programming GuidelinesIn this list,you can tick off whether your test case adheres to the general programming guidelines with respect to performance. If any of these characteristics do not apply to your test case, feel free to skip them. For later regression testing, you can e
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 70
Further Information
Service Marketplacehttp://service.sap.com/performancehttp://service.sap.com/sizinghttp://service.sap.com/quicksizing
Public Webwww.sap.com/benchmark
Related Workshops/Lectures at SAP TechEd 2003SM101 Performance, Scalability and Sizing of mySAP Business Solutions
Wed Oct 1 02.00-03.00 pm, Room L3Thu Oct 2 11.00-12.00 am, Room L1
SM205 Capacity Planning when Upgrading to SAP R/3 EnterpriseWed Oct 1 11.00-12.00 am, Room 9
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 36
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 71
Questions?
Q&A
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 72
Feedback
Please complete your session evaluation anddrop it in the box on your way out.
Thank You !
The SAP TechEd ’03 Basel Team
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 37
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 73
Solution to # 1 - Indexes With Different Operators
The results of index use may be different for different databasesystems.
Case 1: The database checks NAME in the index. Most database systems will not check STREET in the index but instead will read the data blocks.Case 2: The index is not used.Case 3: Both NAME and CITY are checked in the index.Case 4: Most database systems will use all three index columns by splitting the values for CITY. Case 5: Both NAME and CITY are checked in the index. Most database systems will also check STREET in the index. Case 6: All database systems will only check NAME and CITY in the index.Case 7: Most database systems will only check NAME and CITY in the index, but not STREET. Case 8: All database systems will only check NAME in the index.
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 74
Solution to # 2 – Buffering
Question no. 1: Yes, it makes sense to buffer a relatively static currency conversion table
In the SAP system, table TCURR is buffered
Question no. 2: No, because a table which includes material stock information is subject to frequent changes
In the SAP system, table MARD is not allowed to be buffered
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 38
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 75
Solution to # 3 - Read Modules
It does not make sense to write a read module for an already buffered table, because it is a waste of memory.
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 76
Solution to # 4 - Array Access
With transaction ST05, you can see that the database behaves exactly the same in both cases.
As long as you do not program an ‘UP TO n rows’ in ABAP, the database gets as many table rows as possible per communication step (as many as fit in 32K).
However, you will notice differences in memory behavior for eachmethod.
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 39
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 77
Solution to # 5 – Parallel Processes
Two tasks per second.
In this case, and if there is ideal scheduling, two parallel processes are sufficient to achieve optimal throughput.
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 78
Solution to # 6 - Internal Tables I
Runtimes for different reads should be comparedTypical runtimes should be seenDependence on N should be discussedDependence on address in table (beginning or end) should be discussed
Fastest read access is independent of table size: read with index on standard or sorted table and read hashed table with full table key
0,0
0,5
1,0
1,5
2,0
2,5
3,0
3,5
4,0
4,5
5,0
0 1000 2000 3000 4000 5000 6000 7000 8000 9000
no of table lines
runt
ime
(mic
ro s
ec)
standard table with index sorted table with index hashed table with table key
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 40
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 79
Solution to # 6- Internal Tables II
Medium fast read access has a logarithmic dependence of table sizeRead standard table with key binary search, where table must be sorted in advanceRead sorted table with key Read sorted table with table key (slower because table key has an additional dummy field, without extra information, which has to be checked)
0,0
2,0
4,0
6,0
8,0
10,0
12,0
0 1000 2000 3000 4000 5000 6000 7000 8000 9000no of table lines
runt
ime
(mic
ro s
ec)
standard table (binary search) sorted table with table key sorted table with key
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 80
Solution to # 6 - Internal Tables III
Slowest read access depends linearly on table size:Read hashed table with key (not full table key). Note, if the key is full table key syntax check requires the usage with ‘table key’!).Read standard table with table key (no binary search)Not tested, but similar. Key for read sorted table with key must be indentical to the table from the start, otherwise runtime is also linear (full scan).
0,0
200,0
400,0
600,0
800,0
1000,0
1200,0
1400,0
1600,0
1800,0
0 1000 2000 3000 4000 5000 6000 7000 8000 9000
no of table lines
ruun
time
(mic
ro s
ec)
standard table with table key hashed table with key
SAP TechEd ‘03 Basel
© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 41
SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 81
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of Microsoft Corporation.
IBM®, DB2®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390®, AS/400®, OS/390®, OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere®, Netfinity®, Tivoli®, Informix and Informix® Dynamic ServerTM are trademarks of IBM Corporation in USA and/or other countries.
ORACLE® is a registered trademark of ORACLE Corporation.
UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group.
Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.
HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.
JAVA® is a registered trademark of Sun Microsystems, Inc.
JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.
MarketSet and Enterprise Buyer are jointly owned trademarks of SAP AG and Commerce One.
SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies.
Copyright 2003 SAP AG. All Rights Reserved