ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 1
Dr. Ulrich MarquardSAP AG
Performance Analysis & Tuningor:
How to Ensure Scalability
of mySAP.com
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 2
Agenda
Locks on Central Resources
Optimal Use of Central Resources
Share(d) Memory
Guidelines forGuidelines for ServerServer ProgramsPrograms
Parallelization
Optimized Communication
"Linear" Programming
o
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 3
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 4
Agenda
Locks on Central Resources
Optimal Use of Central Resources
Share(d) Memory
Guidelines for Server Programs
Parallelization
Optimized Communication
"Linear" Programming
o
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 5
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?
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 6
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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 7
DB Locks Ensure Consistency of DB LUWs
Lock on record in TAB1
Lock on record in TAB2
Lock on record in TAB3
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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 8
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 9
ÿ 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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 10
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 11
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 12
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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 13
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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 14
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 15
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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 16
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 17
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 18
Lock Management Monitoring
DB01 Database Locks
SM66 System-wideOverview
ST05 PerformanceTrace
SM12 EnqueueOverview
ST05 PerformanceTrace
SAP DB
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 19
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 20
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?
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 21
Agenda
Locks on Central Resources
Optimal Use of Central Resources
Share(d) Memory
Guidelines for Server Programs
Parallelization
Optimized Communication
"Linear" Programming
o
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 22
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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 23
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?
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 24
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 25
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 26
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 27
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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 28
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 29
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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 30
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 31
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 32
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 33
Buffer Monitoring
ST02 Tune Summary – Overview
ST02 Detail Analysis – Menu
SAP
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 34
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 35
Agenda
Locks on Central Resources
Optimal Use of Central Resources
Share(d) Memory
Guidelines forGuidelines for ServerServer ProgramsPrograms
Parallelization
Optimized Communication
"Linear" Programming
o
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 36
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?
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 37
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 38
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 39
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 40
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 41
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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 42
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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 43
Check-Sequence for Buffering
Use of context possible?
Read module with internal buffering
Buffer in Table Buffer via technical settings1
2
3
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 44
Exercise 6
ÿ Implement a Read module with internal buffering for tableSCUSTOM
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 45
Agenda
Locks on Central Resources
Optimal Use of Central Resources
Share(d) Memory
Guidelines forGuidelines for ServerServer ProgramsPrograms
Parallelization
Optimized Communication
"Linear" Programmingo
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 46
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".
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 47
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 48
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 49
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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 50
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 51
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 52
ABAP Contexts
ÿ Simplified and modular definition of complex computations
ÿ Buffering of complex computations on different levels
� Transaction level
� Session level
� Application server level
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 53
Exercise 7
ÿ Analyse and optimize program with nested loops(DSZ400_NESTED_LOOPS,DSZ400_NESTED_LOOPS_PARALLEL,DSZ400_NESTED_SORTED)
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 54
Agenda
Locks on Central Resources
Optimal Use of Central Resources
Share(d) Memory
Guidelines forGuidelines for ServerServer ProgramsPrograms
Parallelization
Optimized Communication
"Linear" Programming
o
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 55
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?
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 56
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 57
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 1WorkProcess 1
WorkProcess 1WorkProcess 1
WorkProcess 1WorkProcess 1
WorkProcess 1WorkProcess 1
WorkProcess 1WorkProcess 1
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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 58
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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 59
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 60
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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 61
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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 62
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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 63
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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 64
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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 65
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 66
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 67
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
Application Server 3
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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 68
DO
Application Server 1
Process
Process
Process
Application Server 3 Application Server 4
Process
Application Server 2
Process
Process
Process
Process Process
Process
Process
Process
Process
Process
Process
Process
Process
Process
Process
Process
Process
Process
Process
Process
Process
Process
Process
Process
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 69
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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 70
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 71
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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 72
ÿ 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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 73
ÿ 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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 74
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 75
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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 76
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 77
Agenda
Locks on Central Resources
Optimal Use of Central Resources
Share(d) Memory
Guidelines forGuidelines for ServerServer ProgramsPrograms
Parallelization
Optimized Communication
"Linear" Programming
o
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 78
Exercise 9
ÿ How long is the minimum response time in a satellite connectionwhen the application needs 30 communication steps per screenchange?
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 79
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
FrontendApplication(e.g. Word)
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 80
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
FrontendApplication(e.g. Word)
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 81
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
FrontendApplication(e.g. Word)
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 82
Exercise 10
ÿ Determine the time for a round trip to your presentationserver
� (Note: Use function "SAPGUI_PROGRESS_INDICATOR andlanguage element "GET RUN TIME ")
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 83
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 84
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 85
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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 86
Solutions to Exercise No. 3
ÿ 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.
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 87
Solutions to Exercise No. 5
ÿ 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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 88
Solutions to Exercise No. 8
ÿ 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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 89
Solutions to Exercise No. 9
ÿ 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
ÿ SAP AG 2000 L01 TechED Hamburg (Dr. Ulrich Marquard) / 90
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.