9/2/2024

Cross Platform Performance

Generated on: 2024-09-02 13:29:21 GMT+0000

Support Content | 1.0

PUBLIC

Original content: https://help.sap.com/docs/SUPPORT_CONTENT/cpp?locale=en-US&state=PRODUCTION&version=1.0

Warning

This document has been generated from the SAP Help Portal and is an incomplete version of the official SAP product documentation. The
information included in custom documentation may not re ect the arrangement of topics in the SAP Help Portal, and may be missing important
aspects and/or correlations to other topics. For this reason, it is not for productive use.

For more information, please visit the https://help.sap.com/docs/disclaimer.

Cross Platform Performance

This is custom documentation. For more information, please visit the SAP Help Portal 1
 9/2/2024
Welcome to the Cross Platform Performance Expert Content Page!

Functional Areas

ABAP Platform

Web Interfaces

Database Performance

Hardware Performance

Network Performance

Memory Management

Load Balancing

Table Buffer(s)

RFC/ALE/IDocs

Analysis Tools

Guided Answers

Support Services

Key Topics: High Response Time

Response Time Overview

High Wait Time Analysis

Load and Generation Time

Enqueue Time

High Frontend GUI Time

High Processing Time

Main Guided Answer

Performance Issue

Performance Survival Guide

KBA 2442365 - Survival Guide for performance analysis on SAP system

General Troubleshooting Guides for Typical Performance Issues

Main Guided Answer for Performance Issues

Diagnosing a General Performance Problem in Workload Analysis

Analysis of Hardware Bottlenecks for Performance

Performance Analysis Procedure for an ABAP Program

How to perform a Network analysis

Troubleshooting Background Jobs for General Performance Issues

Related Technologies and References

Client-Server Technology (BC-CST Expert Content Page)

Technology Troubleshooting Guide Main Page

SAP Business Warehouse Home

SAP HANA and In-Memory Computing

ABAP Development

Monitoring in the CCMS

Single Transaction Analysis

ABAP Connectivity - RFC

Performance Analysis SAP Notes/KBAs

Why NOT to Use an In-Memory Database

This is custom documentation. For more information, please visit the SAP Help Portal 2
 9/2/2024

Schedule an Expert

Have you heard about Schedule An Expert service? Learn everything here.

View our SaE session guidelines in KBA 2480056 - SV-PERF: Guidelines for Schedule an Expert

Product Support Social Media Channels

SAP Product Support Twitter

SAP Support YouTube

SAP Product Support Weibo

Related Content

Troubleshooting

2552474 - Performance Analysis: Guided Answers To Use

2436955 - Step by step instructions on how to use ST12 trace for analysis

2403517 - [WEBINAR] Interpreting traces collected with ST12

2442365 - Survival Guide for performance analysis on SAP system

948066 - Performance Analysis: Transactions to use

2399769 - General Performance: Troubleshooting Questions

2432675 - High Wait Time analysis in SAP system

2428353 - How to analyze high GUI time on SAP systems

2430181 - How To Analyze Work Process Performance Issues - Guided Answers

Performance Tools

755977 - ST12 "ABAP Trace for SAP EarlyWatch/GoingLive"

2169881 - How to trace background job using ST12

1558903 - How To Trace a Portal Scenario Using HttpWatch

1817693 - How to trace the ITS Service "WEBGUI" directly using HttpWatch?

1697063 - HttpWatch - Performance Analysis

2126913 - ENQU: The enqueue log

2383809 - How to use the SDF/MON tool to analyse performance issues

1817724 - How to create HttpWatch trace to troubleshoot BSP related problems

2255214 - Analyze CRM UI performance issues on backend using STAD

1608474 - Recording end-to-end traces for root cause analysis

2879724 - How to analyze performance traces with the pro le data analyzer

Database Performance

332677 - Rebuilding fragmented indexes

1171650 - Automated Oracle DB parameter check

2087573 - Roadmap for performance problem analysis

1732157 - Collecting diagnosis information for SAP HANA [VIDEO]

1817553 - Checklist for performance problems in SAP Oracle Databases

2186006 - DB6: How to match an SAP work process with database application handle [VIDEO]

Network Performance

1100926 - FAQ: Network Performance

500235 - Network Diagnosis with NIPING

This is custom documentation. For more information, please visit the SAP Help Portal 3
 9/2/2024
Other Relevant Performance Analysis Notes

8963 - De nition of SAP response time/processing time/CPU time

1395160 - Priority de nition of SAP incidents - EPM

162991 - Generation tools for ABAP programs SGEN

2085980 - New features in memory management as of Kernel Release 7.40

2430134 - decision tree - How to Determine Which Component a Performance Issue Belongs to

ABAP Platform Performance Analysis

This space introduces you to the overview of performance factors of ABAP platform, and the trouble shooting guide of analyzing individual factors.
Including Workload Analysis, Load Balancing, Work processes performance, ENQUEUE performance and so on.

Performance Factors Overview

Support Service Related to Performance Analysis (Product Support BTP - ABAP Platform)

Load Balancing (Product Support BTP - ABAP Platform)

SAP Memory Management (Product Support BTP - ABAP Platform)

Network Performance Analysis (Product Support BTP - ABAP Platform)

Response Time Overview (Product Support BTP - ABAP Platform)

Remote Function Call (RFC) (Product Support BTP - ABAP Platform)

Key Components of Response Time

This section contains an introduction to the following key components of Response Time and the general guide of troubleshooting.
For more details, visit Expert Content Page Workload Analysis and Response Time

To drill down to the key components, check the below Expert Content Pages:

High Wait time Analysis

Load and Generation Time

Enqueue Time

High Frontend GUI Time

High Processing time

Workprocesses Performance Analysis

KBA 2430181 - How To Analyze Work Process Performance Issues - Guided Answers

Expert Content Page SAP Dispatcher and Taskhandler

SAP Help Page Monitoring in the CCMS - Global Work Process Overview

Load Balancing

Expert Content Page SAPGUI load Balancing

Expert Content Page Load balancing via SAP Web Dispatcher

Expert Content Page Batch Jobs Load Balancing

RFC Resource and Load Balancing:

SAP Help Page Con guration of System Resources for aRFC, tRFC, qRFC

SAP Help Page RFC Performance Pro le

This is custom documentation. For more information, please visit the SAP Help Portal 4
 9/2/2024
Enqueue Performance & Enqueue Time

Enqueue time is used to request and set SAP locks by making use of the enqueue work process. Typically, this component of the dialog response
time is rather small, usually less than 5 ms.

Related SAP Notes:

97760 - Enqueue: Performance and resource consumption

2252679 - How to analyze an enqueue lock problem

2126913 - ENQU: The enqueue log

2013043 - Performance Problems with Enqueue Work Process

2019532 - Performance of integrated enqueue server

Expert Content Page:

Enqueue Performance : Analysis

Internet Communication Manager (ICM)

The ICMan process is responsible for Internet communication within a SAP Web Application Server. It describes how a TCP/IP request with an
standard protocol on top (e.g HTTP/S) is routed into an ABAP context or to a J2EE engine (in case of double stack system).

Related SAP Notes:

2149132 - ICM performance checks

Expert Content Page:

SAP Internet Communication Manager

Remote Function Call (RFC)

Remote Function Call (RFC)

transactional RFCs

queued RFCs

queued RFCs

Purpose
The purpose of this page is to illustrate how the qRFC framework functions and how qRFCs are related to tRFCs. It's main purpose is not as a
troubleshooting resource but a knowledge resource.

Purpose

Overview

qRFC Concepts

Outbound qRFCs

Schedulers (QSENDDEST)

1 Call - 1 queue - 1 LUW

2 Calls - 1 queue - 2 LUWs

Inbound qRFCs

Schedulers (QIWKTAB)

1 Call - 1 Queue - 1 LUW

Overview

This is custom documentation. For more information, please visit the SAP Help Portal 5
 9/2/2024
Like tRFCs, queued RFCs (qRFCs) are a an abstracted type of RFC call. They are not physical RFC calls like synchronous and asynchronous RFC
calls. qRFCs are an extension on the tRFC framework, allowing one to serialize (i.e. set and enforce the order of execution) multiple tRFC LUWs. As
such, qRFC calls use the same or similar framework function modules and tables as tRFC calls, as well as additional framework FMs and tables to
track serialization and monitor resources.

Because qRFCs are an extension of tRFCs, we will be assuming the transactional RFCs Expert Content page has been read before reading this
page, and that the tRFC framework FMs and basis tables and their roles are well understood

Once you understand how the tRFC framework functions, most of the information you need to understand qRFCs is contained in SAP Help Page
Queued Remote Function Call (qRFC).

As such, this page will be dedicated to emphasizing key concepts and connecting various examples of qRFC scenarios to the transactions, screens,
traces, and records you would nd in an ABAP AS system.

qRFC Concepts
qRFCs are classi ed by the direction in which they're processed. There are two classi cations, Outbound and Inbound.

To call an Outbound qRFC, the syntax is the same, however, the outbound queue name has to be de ned rst by calling TRFC_SET_QUEUE_NAME

CALL FUNCTION 'TRFC_SET_QUEUE_NAME'

EXPORTING QNAME = <queue_name>

CALL FUNCTION <func_name> IN BACKGROUND TASK

[AS SEPARATE UNIT]
[DESTINATION <dest>]
<parameter_list>.

To Call an Inbound qRFC, the inbound queue name must be set by rst calling TRFC_SET_QIN_PROPERTIES

CALL FUNCTION 'TRFC_SET_QIN_PROPERTIES'

EXPORTING
QOUT_NAME = <queue_out_name>
QIN_NAME = <queue_in_name>

CALL FUNCTION <func_name> IN BACKGROUND TASK

[AS SEPARATE UNIT]
[DESTINATION <dest>]
<parameter_list>.

(Note that the inbound qRFC is rst placed in an outbound queue prior to being transferred to the destination; this is why the parameter
QOUT_NAME is available here as well. If no outbound queue name is speci ed, QIN_NAME is also used as the outbound queue name.)

qRFC calls, in addition to sharing the same properties as tRFC calls, are assigned to queues using the TRFC_SET_QUEUE_NAME or
TRFC_SET_QIN_PROPERTIES FMs.

qRFC LUWs share the same properties as tRFC LUWs, with the following exceptions: They...

Are guaranteed to be executed in a predictable order; i.e. Are serialized based on client, queue names, destination, and time stamp.

Will be prevented from executing if a predecessor LUW encounters an error.

Outbound qRFCs
This is custom documentation. For more information, please visit the SAP Help Portal 6
 9/2/2024
Serialization of Outbound qRFC LUWs:

In addition to the FMs and tables inherited from the tRFC framework:

The following Function Modules are a part of the outbound qRFC framework:

QDEST_RUN (SAPLQOWK) - Called by the qRFC client step to activate the Outbound Scheduler (aka Send Scheduler) if not already active.

QDEST_RUN_DESTINATION (SAPLQOWK) - Called by the Outbound Scheduler to activate the scheduler for a speci c destination (the
Destination Scheduler). The destination scheduler is responsible for determining the execution order of LUW registered to that destination.

TRFC_QOUT_SEND (SAPLORFC) - Called by the Destination Scheduler. Replaces ARFC_RUN_NOWAIT. it is called to start LUW execution for
a queue with no dependencies (i.e. the LUW is next in the queue to be executed).

The following tables are a part of the outbound qRFC framework:

QSENDDEST - Contains the status of the Outbound Scheduler as well as the Destination Scheduler for each registered outbound
destination.

TRFCQOUT - Analogous to ARFCSSTATE, it records the queue associated with each FM call as well as the timestamp the LUW was
registered.

QIWKTAB - Analogous to QSENDDEST but for registered inbound queues.

Schedulers (QSENDDEST)
There are two main types of outbound schedulers. Each system has 1 system-wide Outbound Scheduler (%QSEND_SCHEDULER, sometimes
referred to as the Send Scheduler), and as many Destination Schedulers as there are registered destinations in SMQS.

The state of these schedulers is tracked via the QSENDDEST table.

SMQS and QSENDDEST:

This is custom documentation. For more information, please visit the SAP Help Portal 7
 9/2/2024

The "Scheduler Information" section in SMQS shows the status of the system-wide Outbound Scheduler. While the table below shows the status of
each Destination Scheduler.

The Outbound Scheduler (%QSEND_SCHEDULER) is "activated" (i.e. an ABAP session for that scheduler is created) when QDEST_SEND is called.
A Destination Scheduler (e.g. NONE or S4C from above) is "activated" when QDEST_RUN_DESTINATION is called.

The "Host ID" eld tells you on which host that particular scheduler is running (or, if the state is INACTIVE, ran last).

Each scheduler should correspond to at most 1 ABAP session. If the state of a scheduler is INACTIVE, then there should be 0 ABAP sessions acting
as that scheduler.

When the schedulers are not INACTIVE they should be able to be seen in SM04. For example (in no particular order):

The session with QDEST_RUN_DESTINATION is the destination scheduler under which the LUW is being executed

The session with Z_CPI_WORK_WAIT is the session which is actually executing the function modules registered in the LUW
(ZCPI_WORK_WAIT is the rst FM in that LUW).

If the destination is another system, you will not see this session next to the schedulers in SM04 of the sending system.

The session with TRFC_QOUT_SEND is the framework task which calls RFC_PING, ARFC_DEST_SHIP, and ARFC_DEST_CONFIRM in order to
actually execute the LUW

This is custom documentation. For more information, please visit the SAP Help Portal 8
 9/2/2024
And (unfortunately) the Outbound/Send Scheduler does not show QSEND_DEST in the "Application Info.", but "WI=CLI(...)" above is indeed
the session of the Outbound Scheduler.

The call order is illustrated per the red arrows, which will be demonstrated in the next section.

1 Call - 1 queue - 1 LUW

Program

STAD

When called via tRFC, there were three recorded generated, when called via qRFC, ve records are generated

1. qRFC Client

2. Outbound/Send Scheduler (SS)

3. Destination Scheduler (DS)

4. Queue Out (QO)

5. qRFC Server

As with the STAD records from the tRFC tasks, the total response time of qRFC calls is misleading. While all four tasks have a total response time
of ~40 seconds, most of this is task #2, #3, & #4 rolled out waiting for task #5 to nish.

When performance issues occur inside FMs called via the qRFC framework, a proportional increase in roll wait time is expected. Suppose our qRFC
server task has a response time of 1 second and makes about 1 second worth of database requests. Consider the following values:

Task DB time Roll Wait time Performance problem occurs new DB time new Roll Wait time

Server 1 0 and DB time doubles 2 0

QO 0 1 → 0 2

DS 0 1 0 2

SS 0 1 0 2

Total 1 3 2 6

Average 0.25 0.75 0.5 1.5

This leads to misunderstandings when examining the RFC response time in the Workload Monitor (ST03) of systems which make many tRFC/qRFC
calls. This is because the aggregation of this workload data somewhat conceals the actual problem of worsening DB time. Comments often heard

This is custom documentation. For more information, please visit the SAP Help Portal 9
 9/2/2024
are similar to "most of the increase in response time seems to be roll wait time", which is simply a side effect of the tRFC/qRFC framework.

(Note that these times & distributions of time vary depending on the amount of parallel qRFC activity in the system.)

Additionally, note the RFC Server & Client sub records when considering the timeline below.

Timeline

The timeline was constructed from the ST05 trace

This is custom documentation. For more information, please visit the SAP Help Portal 10
 9/2/2024

While the above gure is quite busy, the main points are as follows:

ARFCSSTATE, ARFCSDATA, and ARFCRSTATE are used for qRFC calls in the same way as tRFC calls.

The LUW is executed using the same framework FMs as in a tRFC LUW.

TRFCQOUT is updated in parallel to ARFCSSTATE.

This is custom documentation. For more information, please visit the SAP Help Portal 11
 9/2/2024
The SS and DS periodically check the TRFCQOUT table for newly registered LUWs since the SS/DS was started (this will be
demonstrated later). This ensures only one active instance of the SS and one active instance per destination of the DS is required at
any time.

2 Calls - 1 queue - 2 LUWs

Considering the SS, DS, and QO tasks are periodically checking for newly registered LUWs while inactive, what happens when a second LUW
containing FM calls in the same queue are registered while the SS, DS, and QO tasks are not inactive?

Program

STAD

In this case, there are 6 STAD records created:

(middle click/open in new tab for convenience)

1. qRFC Client

2. Send Scheduler (SS)

3. Destination Scheduler (DS)

4. Queue Out (QO)

This is custom documentation. For more information, please visit the SAP Help Portal 12
 9/2/2024
5. qRFC Server1

6. qRFC Server2

Notice how the second server task doesn't start until the rst one nishes. Also note the RFC sub records, it's the already running QO task that
checks and executes the LUW that was registered second (as opposed to the DS starting a new QO task).

Timeline

Note that the calls to RFC_PING, ARFC_DEST_SHIP, and ARFC_DEST_CONFIRM have been consolidated into a single graphic in this timeline.

This is custom documentation. For more information, please visit the SAP Help Portal 13
 9/2/2024

Inbound qRFCs

This is custom documentation. For more information, please visit the SAP Help Portal 14
 9/2/2024
Inbound qRFCs are a further extension built on outbound qRFCs.

When an inbound qRFC LUW is created, it is rst registered as an outbound LUW in the sending system via the ARFCSSTATE, ARFCSDATA, and
TRFCQOUT tables.

Then, using the outbound qRFC framework, the LUW is transferred to the destination system via a call to ARFC_DEST_SHIP, where the LUW is
saved to the TRFCQSTATE, TRFCQDATA, and TRFCQIN tables (which determine the queues and serialization).

The inbound scheduler is then activated (if not already active) and the LUW is executed via TRFC_QIN_DEST_SHIP.

In addition to tRFC and outbound qRFC tables and function modules, the inbound qRFC framework uses the following function modules:

QIWK_RUN (SAPLQIWK) - Analogous to QDEST_RUN; called by ARFC_DEST_SHIP in the receiving/inbound system to activate the system-
wide inbound scheduler.

TRFC_QIN_ACTIVATE (SAPLIRFC) - Analogous to TRFC_QOUT_SEND. Called by the system-wide inbound scheduler to activate a queue
scheduler for a speci c queue (or a collection of queues as determined by the inclusion of a wildcard when registering queues in SMQR)

TRFC_QIN_DEST_SHIP (SAPLERFC) - Analogous to ARFC_DEST_SHIP. It's inside this ABAP session that the inbound qRFC LUW is actually
executed.

And the following tables:

TRFCQSTATE - Analogous to ARFCSSTATE. Stores the functions module names of each LUW.

TRFCQDATA - Analogous to ARFCSDATA. Store the data required to execute each function module (e.g. import parameters).

TRFCQIN - Analogous to TRFCQOUT. Stores the queuing information for each LUW

QIWKTAB - Analogous to QSENDDEST. However, there is only 1 inbound scheduler for the whole system

Schedulers (QIWKTAB)
There is only one system-wide inbound scheduler in a system.

There is no need for destination schedulers for inbound LUWs as once an LUW is registered in the TRFCQ* tables it is already "in the destination
system" in which is will be executed. All that's left is to execute the inbound LUWs in the correct order.

(It is possible to de ne a "destination with logon data" when registering queue names in SMQR in order to restrict execution to speci c application
servers or under a different user and/or client.)

This is custom documentation. For more information, please visit the SAP Help Portal 15
 9/2/2024
The state of the system-wide scheduler, and the registered queue names, is stored in QIWKTAB.

SMQR and QIWKTAB:

1 Call - 1 Queue - 1 LUW

Program

STAD (STATS)

This is custom documentation. For more information, please visit the SAP Help Portal 16
 9/2/2024

The outbound qRFC framework is utilized by the sending system, and the inbound qRFC framework is utilized by the receiving system.

transactional RFCs

Purpose
The purpose of this page is to illustrate how the tRFC framework actually functions. It's main purpose is not as a troubleshooting resource but as a
knowledge resource; that being said, the more one understands of a process, the better one can troubleshoot it when things go wrong.

Purpose

Overview

Key tRFC Concepts

One Call - One LUW - Destination NONE

Program

ST12 Trace Records

STAT/STAD Records

ST05 Trace Entries

Timeline

Two Calls - One LUW - Destination NONE

Program

STAT/STAD Records

ST05 Trace Entries

Timeline

Two Calls - Two LUWs - Destination NONE

Program

STAT/STAD Records

ST05 Trace Entries

Timeline

One Call - One LUW - Destination <Other System>

Program

STAT/STAD Records
This is custom documentation. For more information, please visit the SAP Help Portal 17
 9/2/2024
ST05 Trace Entries

Timeline

System Availability

Additional Notes

Supplementary Files

Overview

Transactional RFCs (tRFCs) are a type of abstracted/logical RFC call. They are not a physical RFC call like synchronous or asynchronous RFCs;
instead, they consist of several tRFC framework function module calls and tables.This is to ensure that multiple function modules called via the
tRFC framework are executed as a group successfully or not at all, in the same order they were called (i.e. transactionally).

Note that each section on this page is incremental. I will be verbose in the rst examples, and build incrementally on top of previous examples.
Before reading later sections, It's best to read and understand earlier sections as basic information will be omitted from the later sections for
brevity.

Key tRFC Concepts

To call a tRFC, the following syntax is used:

CALL FUNCTION <func_name> IN BACKGROUND TASK

[AS SEPARATE UNIT]
[DESTINATION <dest>]
<parameter_list>.

To close (and execute) a tRFC LUW, call COMMIT WORK

tRFC calls are...

Not executed when they are rst called inside of an ABAP program.

Bundled and executed inside Logical Units of Work (LUWs).

Guaranteed to be executed in the same order they were called within the LUW

Guaranteed to succeed or fail collectively within the LUW

tRFC LUWs...

Are composed of one or more FM calls using the IN BACKGROUND TASK syntax.

Are closed/registered (and possibly executed) when a COMMIT WORK statement is encountered.

Are executed using calls, some synchronous and some asynchronous, to tRFC framework function modules.

Are not guaranteed to be executed in the same order they were closed/registered. (To guarantee the execution order of separate LUWs,
qRFCs must be used.)

Relationship between tRFC calls and tRFC LUWs:

This is custom documentation. For more information, please visit the SAP Help Portal 18
 9/2/2024

The following function modules are apart of the tRFC framework:

<Function Module> (<Program>)

ARFC_RUN_NOWAIT (SAPLARFC) - Used by the Client Step to trigger the tRFC LUW. Provides the LUW ID to the framework task.

RFC_PING (SAPLSRFC) - Called by the Framework Step to check the availability of the chosen destination/receiver system.

ARFC_DEST_SHIP (SAPLERFC) - Called by the Framework Step to tell the Server Step the LUW ID, what function modules to execute, and
in what order. Also provides any required parameters to execute each FM.

ARFC_DEST_CONFIRM (SAPLARFC) - Called by the Framework Step to complete the tRFC LUW on the Server Side/receiving system. Clears
entries from the ARFCRSTATE table in the receiving system.

The following tables are apart of the tRFC framework:

ARFCSSTATE (aRFC Send State) - Tracks the status of outgoing tRFC LUWs and the FM calls in each LUW. Tracks the order in which to call
each FM via the ARFCLUWCNT eld.

ARFCSDATA (aRFC Send Data) - Contains the information required (e.g. input parameters) to execute the FMs called via tRFC so they may
be called anytime at a later date

ARFCRSTATE (aRFC Receive State) - Tracks the status of incoming tRFC LUWs

tRFC LUWs Get their own ID. It's composed of four elds ARFCIPID, ARFCPID, ARFCTIME, and ARFCTIDCNT . This ID is visible in
the ARFCSSTATE table (among others) and identi es which LUWs each FM call belongs to.

This is custom documentation. For more information, please visit the SAP Help Portal 19
 9/2/2024
For example, the following two entries belong to the same tRFC LUW as they share the same values for ARFCIPID, ARFCPID, ARFCTIME,
and ARFCTIDCNT (Note the ARFCLUWCNT eld, which tracks the order in which each FM is called)

tRFC LUWs in the sending/client system...

Exist in the sender system (i.e. the system that executed the code containing the CALL FUNCTION ... IN BACKGROUND
TASK and COMMIT WORK statements )

Are recorded in the ARFCSSTATE table (one record per FM).

Are not actually executed on this system (unless the receiving system/destination is the same system).

tRFC LUWs in the receiving/server system...

Exist in the receiving system.

Are recorded in the ARFCRSTATE table (only one record per LUW; note this is different than ARFCSSTATE!)

Are actually executed on this system.

To monitor tRFCs in the sending/client system, you can use:

Transaction SM58

The tRFC LUW ID is called Transaction ID in this screen and has no relation to the dialog Transaction ID you would nd in STAD or ST05 traces.
For example, here is the STAD record that executed one of the above LUWs (right-most column is the dialog Transaction ID):

SE16 > ARFCSSTATE

(Note the value of the ARFCSTATE eld does not precisely match the Status Text column in SM58.In this case SENDED = Transaction
executing)

To monitor tRFCs in the receiving/server system, you can use SE16 > ARFCRSTATE:

This is custom documentation. For more information, please visit the SAP Help Portal 20
 9/2/2024

Note how there is only one entry in ARFCRSTATE for each tRFC LUW, compared to ARFCSSTATE, which contains one entry for each FM called
in a LUW.
(It is often unnecessary to examine the ARFCRSTATE table when investigating tRFC problems)

One Call - One LUW - Destination NONE

Program

ST12 Trace Records

2-1 - The step generated by the session that actually executed the called FM (tRFC Server step)

2-2 - The step generated by the main program (tRFC Client step)

2-3 - The tRFC framework step

The Framework task is only captured if you have "tRFC framework" checked in the "Collect traces" dialog.

This is custom documentation. For more information, please visit the SAP Help Portal 21
 9/2/2024

STAT/STAD Records
The following STAD records were generated from this call:

The generated STAD records are as follows (only the relevant sections have been included):

1. 2. 3.
tRFC Client Step tRFC Framework Step tRFC Server Step

Link to File Link to File Link to File

Important points regarding the STAD records

The client call to Z_CPI_WORK_WAIT is made on a dummy connection and is not a real RFC call.

Connection Id - 00000000000000000000000000000000

Destination - a_rfc

RFC type - synchronous

The server call record for Z_CPI_WORK_WAIT is also recorded under a dummy connection, but with a slightly different RFC type

Connection Id - 00000000000000000000000000000000

Destination - a_rfc

RFC type - bgRFC replay (synchronous)

(on older kernel versions, RFC type can be listed as tRFC (synchronous) )

ARFC_RUN_NOWAIT and ARFC_DEST_SHIP will always have a runtime larger than that of the called FM(s) (in this
case, Z_CPI_WORK_WAIT ). Only when the runtime of ARFC_RUN_NOWAIT and A_RFC_DESTSHIP is signi cantly higher than the target
FM(s) should you be suspicious of the tRFC framework, but the much more likely explanation is a network, gateway, or RFC resource issue,
and not the actual framework itself.

Note the total response time of the RFC tasks is >10 seconds, but this is not the true response time, as the framework task spends 4.682
seconds rolled out, waiting for the server task.

ST05 Trace Entries

Unfortunately there is no adequate way to visualize and show each step using the formatting provided by the Expert Content framework, instead,
read sheet 1 Call - Destination NONE in the following annotated Excel le:

This is custom documentation. For more information, please visit the SAP Help Portal 22
 9/2/2024

And follow along using the following timeline:

Timeline

Note:

Each vertical bar represents an ABAP session.

Vertical scale is not proportional to time spent/required

WPs do not communicate to each other directly during RFC calls, but through the gateway. Therefore, anytime there is an arrow
representing RFC communication, remember that the gateway is involved, receiving, handling, and sending requests between the
sessions/WPs.

This is custom documentation. For more information, please visit the SAP Help Portal 23
 9/2/2024

Two Calls - One LUW - Destination NONE

Program

STAT/STAD Records
This is custom documentation. For more information, please visit the SAP Help Portal 24
 9/2/2024

The generated STAD records are as follows (most convenient to open in a new tab):

1. 2. 3.
Client Step Framework Step Server Step

Link to File Link to File Link to File

Important points regarding the STAD records

No additional tasks are needed when we increase the number of calls in one LUW; i.e. the framework task ships
both Z_CPI_WORK_WAIT calls to a single tRFC Server Task which executes both called FMs.

ARFC_DEST_SHIP has a runtime close to the total runtime of the called FMs as we would expect.

(One of the calls to Z_CPI_WORK_WAIT has a recorded runtime of 0 ms which is not correct; you can see the actual runtime in the ST05
performance traces)

ST05 Trace Entries

Please refer to sheet 2 Calls - 1 LUW - Dest NONE in the annotated Excel le:

Timeline
Note that ARFCSSTATE is not updated between each execution of Z_CPI_WORK_WAIT, thus the server task attempts to execute all FMs in a tRFC,
and only once all FMs execute successfully are the entries in ARFCSSTATE updated by the framework task.
If one FM in a tRFC LUW fails, the entire LUW is put into an error state.

This is custom documentation. For more information, please visit the SAP Help Portal 25
 9/2/2024

Two Calls - Two LUWs - Destination NONE

(One call per LUW)

Program

This is custom documentation. For more information, please visit the SAP Help Portal 26
 9/2/2024

STAT/STAD Records

The generated STAD records are as follows (most convenient to open in a new tab):

1. 2. 3. 4. 5.
Client Step Framework Step Server Step Framework Step Server Step

LUW 1 LUW 2

Link to File Link to File Link to File Link to File Link to File

Important points regarding the STAD records

Another framework step is needed here as two LUWs were created (we called Z_CPI_WORK_WAIT twice followed by COMMIT WORK each
time)

The Transaction ID is equal for all steps, despite there being multiple LUWs. (Thus, dialog Transactions and LUWs ID are not directly related.)

ST05 Trace Entries

Please refer to sheet 2 Calls - 2 LUWs - Dest NONE in the annotated Excel le:

Timeline

This is custom documentation. For more information, please visit the SAP Help Portal 27
 9/2/2024

One Call - One LUW - Destination <Other System>

Program

This is custom documentation. For more information, please visit the SAP Help Portal 28
 9/2/2024
The test program is being executed on Y59, and the target system is Y57; therefore:

Y59 is the sending system

Y57 is the receiving system

STAT/STAD Records
Sending/Client System:

Receiving/Server System:

The generated STAD records are as follows (most convenient to open in a new tab):

1. 2. 3.
Client Step Framework Step Server Step

Sending System Receiving System

Link to File Link to File Link to File

Important points regarding the STAD records

The Dialog Transaction ID is the same across systems/application servers

The Connection ID is the same in the client calls of the Framework Task and the server calls of the Server Task

ST05 Trace Entries

Please refer to sheet 1 Call Dest <other system> in the annotated Excel le:

This is custom documentation. For more information, please visit the SAP Help Portal 29
 9/2/2024

Timeline
We can see the framework task still resides on the sending system, and only the server tasks is carried out on the receiving system.

Note that two gateways are now involved in communication, the GW in the app server of the sending system and the GW of the app server in the
receiving system.

This is custom documentation. For more information, please visit the SAP Help Portal 30
 9/2/2024

System Availability

Another key concept of the tRFC is that the destination does not need to be available at the time of calling the FM/registering the LUW.

If the framework task could not complete the tRFC LUW, the information needed to execute the LUW is still contained in
the ARFCSSTATE & ARFCSDATA tables and can be executed at a later time.

Check the System Availability section of SAP Help Page Transactional RFC (tRFC) for more information on this behavior:

This is custom documentation. For more information, please visit the SAP Help Portal 31
 9/2/2024
The following SAP Note contains additional information on how to in uence this behavior:

SAP Note 1902003 - Many ARFC* jobs in SM37 and many "Error when opening an RFC connection" in SM58 at the same time

Additional Notes
SAP Note 1483845 - Using the report RSARFCEX (to execute LUWs not yet executed; e.g. in error state)

Supplementary Files

Remote Function Call (RFC)

Communication between applications of different systems in the SAP environment includes connections between SAP systems as well as between
SAP systems and non-SAP systems. Remote Function Call (RFC) is the standard SAP interface for communication between SAP systems. RFC calls
a function to be executed in a remote system.

For more detailed Fundamentals and Concepts about Remote Function Call (RFC), read:

SAP Help Page RFC

Expert Content Page ABAP Connectivity - RFC

RFC Types

SAP Help Page queued RFCs

SAP Help Page transactional RFCs

Execution ow

The below illustration shows an ECC system communicating with other systems (another ECC, BW, SCM, CRM) through Remote Function Calls.

This is custom documentation. For more information, please visit the SAP Help Portal 32
 9/2/2024

Need quick help? Check KBA 2525793 - How to analyze RFC performance issues - Guided Answers - for RFC performance issues!

RFCs can also occur with non-SAP/Netweaver systems. Read SAP Help Page RFC Communication Scenarios for the details.

RFC Cycle

The below illustration shows the course and measured times of a synchronous RFC from performance analysis perspective.

The gure illustrates the course and measured times of a synchronous RFC, which are displayed in the single-record statistics (Transaction STAD)
and in the workload monitor (Transaction ST03).RFC Cycle shown as follow:

1. Establishing the connection (the CMINIT phase)

2. Data exchange (CMSEND and CMRECEIVE phases)

3. Closing the connection or wait status

4. Repeated data exchange

5. Closing the connection

In this procedure, establishing the connection should take only a few milliseconds. If you nd this status (the CMINIT phase) often in the work
process overview, there may be an overload in the recipient system.

This is custom documentation. For more information, please visit the SAP Help Portal 33
 9/2/2024
2317074 - "timeout during allocate" when starting external programs

1842162 - Connection test SM59: Timeout during allocate

581509 - Reasons for "timeout during allocate"

944792 - Runtime analysis when you start external RFC servers

1333483 - Timeout during allocate of a registered program

During the connection,RFC users are running in the Dialog work process in the receiver system. By specifying RFC user ID, you can monitor the RFC
process in the receiver system.

2180934 - Analysis of Work process in "On Hold" RFC, or Stopped CPIC status

1260137 - Work process status "Stopped RFC" by SAPLARFC (tRFC/qRFC)

1324454 - qRFC scheduler is still set to WAITING status

After the data exchanging, nally, the connection is closed. The recipient work process is free again, and the sender work process continues with
its work.

1520551 - RFC: Connections in Gateway are not closed

RFCs and Network issues

One source of high RFC time can be a potential Network issue. In this case, the systems involved need to be identi ed in order to perform a NIPING
analysis and test latency. Check the following KBA and SAP Note:

2471983 - Identifying RFC connections in STAD and ST03

552845 - FAQ: RFC Statistics in Transactions ST03/ST03N and STAD

After identifying the systems involved, you can perform a NIPING analysis to see if Network is a source of the high RFC time.

Related SAP Notes and KBAs

General performance issues:

2418936 - High RFC time: Performance troubleshooting

2457530 - Performance problems with OLE_FLUSH_CALL, how to analyze

2490095 - ARFC_RUN_NOWAIT is slow

638701 - Starting RFC servers takes too long

2426336 - Performance analysis of external RFC server programs (registered program)

2356090 - GW: RFCs hang 2442915 - GW: RFCs hang (II)

1485789 - QRFC: Long running processes in SM50

2140916 - Performance issues in RFC processing (Oracle)

1946287 - Slow RFC performance shown in ST03N for TASK_VITAL_PERIOD by SAP_WSRT user

2468083 - Hanging RFC session of FM SALC_PERF_REPORT_VALUE in SM04

532918 - “RFC trace generation scenarios”, section 2 “Communication from ABAP to an external program”

Connection issues:

1954118 - Connection Failure with RFC Destination of Started External RFC Server and Memory Leaks with RFC Accept

1403974 - Determining the maximum connections in transaction SMQA

Load balancing:

593058 - New RFC load balancing procedure

103523 - RFC Load Balancing

RFC queue processing:

1272327 - "Max.Runtime" and a generic queue in SMQS and SMQR

527481 - tRFC or qRFC calls are not processed

869399 - * bottlenecks when processing CIF queues (LUWs)

This is custom documentation. For more information, please visit the SAP Help Portal 34
 9/2/2024
1324454 - qRFC scheduler is still set to WAITING status

1493644 - Long running process reading TRFCQIN blocking execution

2334064 - Various issues with qRFC processing after a support package

1051445 - qRFC scheduler does not use all available resources

1623430 - Outbound queue scheduler does not process all LUW’s

Incorrect/Very high RFC time:

2071875 - Incorrect Average RFC Interface Time ("CPIC/RFC") in ST03N Workload Overview

570751 - Incorrect RFC+CPIC time/Roll time wait in ST03

2241334 - ST: Queue time is too long

Workload Analysis and Response Time

This Expert Content Page provides an introduction about how to analyze the workload workload and how to identify key components of high
response time.

Components of the response time

The following SAP Notes provide information about how response time is measured and
contains information about the term in general.

8963 - De nition of SAP response time/processing time/CPU time

1063061 - Information about response time in STAD/ST03

Guideline values when analyzing Average response time/Dialog step are outlined
below.

Wait Time < 10% of total response time (<50ms)

Roll In/Out < 20ms

Roll Wait time < 200ms

Load and Generate < 50ms

Processing time < 2 * CPU

Enqueue time <5ms

DB Time < 40% (Response time – Wait time)

GUI time <200ms

Be aware these are only guideline gures, and are NOT a de nitive indication of a
performance issue.

The following section contains an introduction to the key components of response time and a general troubleshooting guide.

High Wait Time

The dispatcher of the SAP instance receives the incoming request and stores it in the request queue of the appropriate work process type. While
the dispatcher is looking for a free work process, wait time is accumulated. Wait time ends, when the request is being forwarded to a free work
process of the required type. Wait time is the rst component of the overall dialog response time.

Check the number of Dialog work processes in SM50 or TU02 ʻrdisp/wp_no_dia’

Check for long running processes consuming a high number of Work Processes

Check for Work processes in PRIV Mode, this can indicate insufficient extended memory

Is high wait time the Root cause of the poor performance or a symptom of another issue

Activate the /SDF/MON to analyze the running status of work processes

High GUI Time

This is custom documentation. For more information, please visit the SAP Help Portal 35
 9/2/2024
Analysis should focus on Front End: Front-End Ping (Network Check), Front-End Hardware, High Volume of Data Transferred, Many Roundtrips. If
you discover that the GUI time is high despite a relatively small volume of data, this can be for two reasons: there may be a hardware bottleneck

on the presentation server or a network bottleneck. Often, the simplest way to analyze this further is to lter out the users who typically
experience these problems from the single-record statistics.

High GUI Time, can sometimes be the result of a non-optimally con gured SAP Easy Access Menu. Check for high GUI Times associated with the
transaction SESSION_MANAGER, if high times are identi ed it is a good idea to run the report ʻEASY_ACCESS_NUMBER_OF_NODES’ via SE38.
This report identi es the number of menu nodes con gured per user. A high number of menu nodes increases GUI time and reduces performance.

When using SAP Easy Access Menu:

Menu should not contain more than 1000 entries (For comparison: The complete SAP menu contains 70,000 entries). The Tree is loaded to the
user context at a glance. A high number of menu entries leads to high memory consumption on the application server and to long response times
for the menu.

Related SAP Notes

2428353 - How to analyze high GUI time on SAP systems

851012 - SAPGUI: Performance trace - technical details

305363 - Create frontend trace le

500235 - Network Diagnosis with NIPING

203617 - ʻHigh memory consumption with Easy Access menu’

357693 - ʻRedundancy avoidance in Easy Access’

High Roll Wait time

In general roll wait time measures external communications and this could be GUI communication or RFC communication.

A way to check if the problem is in GUI communication or if is RFC communication is checking the GUI time and frontend network time. If you nd
high times then the problem is most likely to be related with GUI communication.

If not then RFC communication should be investigated.

Review SAP note 364625 that explains you GUI time and fronted time, and also provides details of how to review these times on a system.

Related SAP Notes:

2426336 - Performance analysis of external RFC server programs (registered program)

2418936 - High RFC time - Performance troubleshooting

Please see the detail information about GUI time analysis in the following section ʻ High GUI Time ʻ.

High Database time

If data is read from the database server or changed in the database, these actions are indicated as database time (Av. DB Time). Database time is
measured from the moment the database request is sent to the database server and runs until the moment the data is returned to the
application server.

Check for expensive SQL causing high load on the system

Check I/O performance stats

High Enqueue time

Enqueue time is used to request and set SAP locks by making use of the enqueue work process. Typically, this component of the dialog response
time is rather small, usually less than 5 ms.

This is custom documentation. For more information, please visit the SAP Help Portal 36
 9/2/2024

Related SAP Notes:

97760 - Enqueue: Performance and resource consumption

2252679 - How to analyze an enqueue lock problem.

2126913 - ENQU: The enqueue log

2013043 - Performance Problems with Enqueue Work Process

2019532 - Performance of integrated enqueue server

Related Expert Content Page:

Enqueue Performance : Analysis

High load and generate time

Load and Generate time is the amount of the time taken by work process to copy and generate or to load and generate abap code and screens for
the User request. The load and generator time is high the problem is the buffer sizes is too small (TP program or buffers and CUA buffers).

Check in ST02, verify if the program buffer is sized sufficiently

Up to 10,000 swaps per day is acceptable for the Program Buffer.

HitRatio% and % Freespace should always be considered when analysing Buffer Size

Always ensure sufficient main memory is available before making buffer increases and that all changes are tested before promoting to a
production environment.

Related SAP Note:

1230076 - Generation of ABAP loads: Tips for the analysis

High Processing time

Check Operating System Monitor for a CPU Bottleneck:

994025 - Virtualized OS environments in the operating system monitor

1084019 - OS07N: New operating system monitor

Database Performance Analysis

This page offers help to customers and support engineers analyze Database performance, including all the database platform, Oracle, MSSQL,
HANA, IBM, MAXDB etc.

DBA Cockpit

Related Content

ORACLE

Related SAP Notes and KBAs

Expert Content Pages

SAP HANA

Related SAP Notes and KBAs

Expert Content Pages and SAP Help Pages

Performance Monitoring and Analysis

DB2 UDB for LINUX, UNIX and Windows

This is custom documentation. For more information, please visit the SAP Help Portal 37
 9/2/2024
Related SAP Notes and KBAs

Expert Content Pages and SAP Help Pages

MAXDB

Related SAP Notes and KBAs

Expert Content Pages and SAP Help Pages

SAP Sybase ASE

Related SAP Notes and KBAs

Expert Content Pages and SAP Help Pages

SQL Server

Related SAP Notes and KBAs

Expert Content Pages and SAP Help Pages

DBA Cockpit
The entry screen of the DBA Cockpit is divided into following areas:
The DBA Cockpit is a platform-independent tool that you can use to
monitor and administer your database. It provides a graphical user
interface (GUI) for all actions and covers all aspects of handling a
database system landscape. You can run the DBA Cockpit locally on an
SAP NetWeaver-based system by calling the DBACOCKPIT transaction.

Universal to all Databases

Analysis depends on the Database Version and Release

Database Con guration and layout can be checked

SQL Cache can be analysed for most expensive SQL

A HTTP Connection is necessary to access the Web-Dynpro
DBACOCKPIT, for some customers this is the only option to access
the dbacockpit

Related Content

KBA 2125429 - Performance Troubleshooting Guide - DBACockpit

[VIDEO]

SAP Help Page The DBA Cockpit

ORACLE

Related SAP Notes and KBAs

1171650 - Automated Oracle DB parameter check

1431798 - Oracle 11.2.0: Database Parameter Settings

1888485 - Database Parameter for 12.1.0.2

618868 - FAQ: Oracle performance

Expert Content Pages

Oracle

Tuning Oracle

SAP HANA

This is custom documentation. For more information, please visit the SAP Help Portal 38
 9/2/2024
Related SAP Notes and KBAs

2000002 - FAQ: SAP HANA SQL Optimization

1999930 - FAQ: SAP HANA I/O Analysis

2000000 - FAQ: SAP HANA Performance Optimization

1732157 - Collecting diagnosis information for SAP HANA [VIDEO]

1999998 - FAQ: SAP HANA Lock Analysis

1813020 - How to generate a runtime dump on SAP HANA

1999997 - FAQ: SAP HANA Memory

1999993 - How-To: Interpreting SAP HANA Mini Check Results

2443066 - Standard transactions or standard reports have poor performance after Database migration to SAP HANA Databas

Expert Content Pages and SAP Help Pages

SAP HANA and In-Memory Computing

SAP HANA Troubleshooting and Performance Analysis Guide → Statement Performance Analysis

SAP HANA Cockpit Help Portal → Administration and Monitoring Functions

Performance Monitoring and Analysis

Monitoring and Analyzing with the Performance Monitor

Analyzing the performance of the SAP HANA database over time can help you pinpoint bottlenecks, identify patterns, and forecast
requirements.

Monitoring and Analyzing Threads

Analyzing the threads running in the SAP HANA database can be helpful when analyzing the current system load.

Monitoring and Analyzing Expensive Statements

Use Expensive Statements to analyze individual SQL queries whose execution time was above a con gured threshold.

Monitoring and Analyzing Statements with SQL Plan Cache

Use the SQL plan cache to get an insight into the workload of the SAP HANA database as it lists all statements currently cached in the SAP
HANA database.

Monitoring and Analyzing Sessions

Use the Sessions tile to monitor all sessions in your landscape.

Monitoring and Analyzing with the Statements Monitor

Analyzing the current most critical statements running in the SAP HANA database can help you identify the root cause of poor
performance, CPU bottlenecks, or out-of-memory situations. Enabling memory tracking allows you to monitor the amount of memory used
by single statement executions.

Managing Statement Hints

Use the Manage statement hints to add statement hints to an SQL statement without modifying the actual statement in the application.

Analyzing Statement Performance

Analyzing statement performance helps you understand performance issues of a query execution and other query execution aspects of the
SAP HANA database.

DB2 UDB for LINUX, UNIX and Windows

Related SAP Notes and KBAs

899322 - DB6: DB2 9.1 Standard Parameter Settings

1086130 - DB6: DB2 9.5 Standard Parameter Settings

1329179 - DB6: DB2 9.7 Standard Parameter Settings

1692571 - DB6: DB2 10.1 Standard Parameter Settings

This is custom documentation. For more information, please visit the SAP Help Portal 39
 9/2/2024
1851832 - DB6: DB2 10.5 Standard Parameter Settings

2303771 - DB6: DB2 11.1 Standard Parameter Settings

Expert Content Pages and SAP Help Pages

SAP on DB2 for Linux, UNIX, and Windows

DB2 Performance

Physical read/write Analysis

MAXDB

Related SAP Notes and KBAs

725489 - SAP MaxDB performance analysis tools

819641 - FAQ: SAP MaxDB performance

819324 - FAQ: SAP MaxDB SQL optimization

2056680 - SAP MaxDB runtime analysis: Restore data backup

1357553 - MaxDB / liveCache Performance on HP-UX

Expert Content Pages and SAP Help Pages

SAP MaxDB

Tuning SAP MaxDB

SAP Sybase ASE

Related SAP Notes and KBAs

1766238 - FAQ: Query Optimization -in process

1764611 - FAQ: SAP Sybase ASE Update Statistics -in process

2162183 - Frequently asked questions on SAP ASE for Business Suite

2371160 - FAQ: BW archiving to SAP IQ performance considerations

1642301 - Collecting diagnostic data for Sybase ASE support

2087323 - SYB: Important solved problems for SAP Applications running on SAP ASE

Expert Content Pages and SAP Help Pages

SAP ASE HOME

Performance and Tuning

SQL Server

Related SAP Notes and KBAs

521750 - FAQ: SQL Server 2000 I/O performance

987961 - FAQ: SQL Server I/O performance

1152848 - FAQ: SQL Server Wait Events

555223 - FAQ: Microsoft SQL Server in NetWeaver based systems

Expert Content Pages and SAP Help Pages

SAP on SQL Server

SQL Performance

This is custom documentation. For more information, please visit the SAP Help Portal 40
 9/2/2024

Decision Trees and Guided Answers

This page offers help to customers by providing a step by step guide through an issue or process. Topic experts create trees by documenting the
steps they go through when analyzing an issue or following a complex process. As knowledge grows in a content area, trees can grow to include
new branches, accommodating new or unforeseen circumstances or scenarios. Conversely branches can be pruned if their content becomes
obsolete. This allows the tree to remain healthy and relevant to the task or process which it documents.

Guided Answer Trees

Main Tree

Master Guided Answer : Performance issues

General performance

Transactions to use for Performance Troubleshooting

How To Analyze Work Process Performance Issues

How to Determine Which Component a Performance Issue Belongs to

Diagnosing a General Performance Problem in Workload Analysis

Troubleshooting Background Jobs for General Performance Issues

Performance Analysis Procedure for an ABAP Program

Hardware

Analysis of Hardware Bottlenecks for Performance

Expensive SQL analysis

Optimizing Expensive SQL Statements

Memory

Analyzing the Efficiency of Table Buffering

Analyzing and Con guring Memory to Increase Performance

RFC

How to analyze RFC performance issues

Network

How to perform a Network analysis

BW performance

Performance Analysis of BW Queries

Hardware Performance

SAP OS Monitor

Operating System Monitor ST06/ST06n/OS07n provide the following functions to analyze the bottleneck for CPU, Memory, le
system, LAN, etc.

This is custom documentation. For more information, please visit the SAP Help Portal 41
 9/2/2024

CPU

The CPU utilization for a non-virtualized environment will always sum up to 100%. User utilization should not exceed a value of 50 to 60%. System
utilization should be below 20% and Idle time should be above 20%. An idle time below 20% will lead to CPU bottleneck situations. IO Wait time is
considered a subset of idle time. It can’t be concluded that a high IO wait time indicates a disk-level issue. IO Wait time includes block IO, raw IO, or
Virtual Memory operations such as paging/swapping. It does not include time spent on tape IO or terminal IO.

Related Content

Guided Answer CPU Analysis in ST06

Memory
• Physical memory: This number gives the size of the RAM of the server.
• Swap size: Con gured swap size: This is the sum of physical RAM and swap/page space. This sum is also known as virtual memory in SAP
systems.
• Swap size: Maximum swap size This gure gives the amount of con gured swap/page space.
• Page: The swap/paging activity on OS level per hour should not be higher than one-fourth the size of the physical RAM for Page in activity on
Windows OS, or one- fth the size of the physical RAM for Swap Out activity UNIX OS. Otherwise, you will observe a decrease in SAP system
performance caused by heavy CPU and I/O utilization.

Related Content

Guided Answer Memory Analysis in ST06

2442188 - decision tree - Analyzing and Con guring Memory to Increase Performance

1121904 - SAP on AIX: Recommendations for paging space

103747 - Performance: Parameter recommendations as of Release 4.0

LAN check by PING

In the operating system monitor (Transaction ST06), select Other Functions • LAN Check by Ping or call the transaction code:OS01.

Related Content

KBA 2443079 - Network performance analysis - LAN check by PING (OS01)

This is custom documentation. For more information, please visit the SAP Help Portal 42
 9/2/2024
Hardware monitoring

There are a number of tools that are available to collect data on your hardware utilization.

SDF/MON - Performance monitoring

The transaction SDF/MON is a powerful in-built feature in all SAP systems that can help collect hardware performance metrics from a number of
areas;

CPU Utilization

Pages in/Pages out

Extended memory utilization

Paging memory

You can set the performance monitor for a daily schedule or for a speci c time when the a performance issue is known to occur. This is defaulted to
take a snapshot of the system performance every 10 seconds. One very useful feature of SDF/MON is viewing the snapshot data in real time
allowing for analysis as the issue occurs.

More information about SDF/MON can be found in KBA 2383809 - How to use the SDF/MON tool to analyse performance issues.

Another useful feature is importing the SDF/MON data into a tool called RSORASTT which can graph the outputs for further analysis.

The tool can be found in the attachments of SAP Note 1299493 - Loadable SAP Support Monitors

The graph below displays SDF/MON data collected for a de ned time period where cpu idle%(1) is graphed for a selected server(2). This is very
helpful as servers can be selected as required. In this case, the cpu idle% does not go below 80% and therefore is acceptable (3).

Nmon - Performance monitoring for AIX and Linux OS systems

The Nmon tool is a very useful too for giving detailed information on OS/hardware performance for AIX and Linux systems. The Nmon tool collects
the hardware performance for output to a .nmon le. This le can then be analyzed by the Nmon analyzer which displays the following;

CPU utilization

Disc write speed

OS/system utilization vs. User utilization

Virtualization

If analysis is taking place on virtualized environment, it is critical that enhanced monitoring functions are activated as per the SAP Notes
highlighted below:

This is custom documentation. For more information, please visit the SAP Help Portal 43
 9/2/2024
General

994025 - Virtualized OS environments in the operating system monitor

536954 - OS data in a cluster environment for OS07

1084019 - OS07N: New operating system monitor

2067546 - ST06/OS07N: Overview note

VMware

2447884 - VMware vSphere with VMware Tools 9.10.0 up to 10.1.5: Performance Degradation on Windows

2161991 - VMware vSphere con guration guidelines

1055767 - Best Practises VMWARE ESX

Windows

1409608 - Virtualization on Windows

1056052 - Windows: VMware vSphere con guration guidelines

Linux

1122387 - Linux: SAP Support in virtualized environments

1122388 - Linux: VMware vSphere con guration guidelines

AIX

1379340 - Extended set of virtualization metrics for AIX Power Systems

Oracle & Solaris

2031893 - Virtualization monitoring with saposcol on Oracle Solaris

Related Content

SAP Notes:

1571179 - System shows high IO-Wait in ST06

2399769 - General Performance: Troubleshooting Questions

Other Useful Resources:

SAP Help Page Operating System Monitor

Expert Content Page Transaction ST06

Guided Answer Enter Transaction Code ST06n to display the Operation System Monitor

Load Balancing
ABAP Logon Group Based Load Balancing

Expert Content Page ABAP Logon Group based Load Balancing

Analysing Workload Distribution

Expert Content Page Tools for Workload Distribution Analysis

This is custom documentation. For more information, please visit the SAP Help Portal 44
 9/2/2024
Related SAP Notes and KBAs

2244136 - Uneven load distribution

593058 - New RFC load balancing procedure

64015 - Description of test program lgtst

26317 - Set up for LOGON group for autom. load balancing

38119 - SAP Logon: Administration of functions

27044 - Login workload Balancing veri cation test

649008 - HTTP load balancing using the SAP message server

118093 - Concepts of de ning 'limits' in logon load balancing

51789 - Poor user distribution in logon distribution

Wiki: Load balancing via SAP Web Dispatcher

Expert Content Page Load balancing via SAP Web Dispatcher

Related SAP Notes and KBAs

908097 - SAP Web Dispatcher: Release, Installation, Patches, Documentation

1026191 - Limitations on the HTTP router protocol in Web Dispatcher

1827131 - Web dispatcher load balancing with CRM system in exible

1040325 - HTTP load balancing: Message Server or Web Dispatcher

RFC Resource and Load Balancing

SAP Help Page Con guration of System Resources for aRFC, tRFC, qRFC

SAP Help Page RFC Performance Pro le

Related SAP Notes and KBAs

593058 - RFC Logon concept and settings to be performed in SMLG

1112104 - Weighted round robin procedure

986373 - Managing RFC Load Distribution

Load Balancing of Batch Jobs

Expert Content Page Batch job load balancing

1508504 - Load balancing in background processing

1530713 - Improved load balancing

Load Balancing of BW extraction Jobs:

2535441 - How to restrict the BW extraction jobs to a speci c host or server group

1626778 - Consulting: Load distribution of BW background jobs

1488762 - Using a server group for BE extraction

SMLG - CCMS Load Distribution

SMLG->GOTO->Load Distribution:

This is custom documentation. For more information, please visit the SAP Help Portal 45
 9/2/2024

Here you can see the current logon instance for the particular logon group and also, if monitored over a period of time, you can check for
imbalance in the load distribution. In conjunction with this you should also check the CPU load and the paging rates for the various servers in ST06
and the response times for the application servers using the Workload monitors in ST03. If you can only establish high response times on one or a
few instances and if the number of calls are distributed unevenly then you can assume a less than optimal load distribution. Another tool that is
useful when analyzing workload distribution is /SDF/MON. This is particularly helpful if the peak load happens on a different timezone. You should
schedule /SDF/MON during the relevant hours as per instructions in KBA 2383809 - How to use the SAP Performance Monitor SDF/MON tool to
analyse performance issues.

NetWeaver Performance Monitoring Checklist (AS ABAP)

For SAP Support to provide proper answers and solutions to performance problems (poor response times or system outages caused by resource
bottlenecks) in a NetWeaver Application Server for ABAP system, the system needs to be con gured correctly and some performance-related
collectors should be running.

If only one of the points below are not met, SAP Support will likely still be able to provide some root cause analysis and possible solutions. As fewer
of these criteria are met, root cause analysis becomes less likely, and in many cases impossible.

The most common "unsolvable" scenarios come from historical performance problems (performance problems which occurred several hours or
more ago, but the system has since recovered or been restarted) in systems with no workload data (ST03) or missing Snapshot Monitoring
(SMON). In these cases, SAP Support can only wait for the problem to occur again once the relevant collectors are turned on.

The following is a checklist for ensuring a system is supportable in the event of a performance problem. By following the list below, you help SAP
Support help you in getting quicker answers and solutions to performance problems.

Click the Summary for a quick reference.

1. Software components ST-PI and ST-A/PI

Why are these important?

How do I check for them?

How do I x them?

Who can help if I encounter a problem?

2. STAT les (STAD)

Why are these important?

How do I check for them?

How do I x them?

Who can help if I encounter a problem?

3. Workload Monitor (ST03) data

Why are these important?

How do I check for them?

How do I x them?

Who can help if I encounter a problem?

4. OS Monitor (ST06) data

This is custom documentation. For more information, please visit the SAP Help Portal 46
 9/2/2024
Why are these important?

How do I check for them?

How do I x them?

Who can help if I encounter a problem?

5. Daily snapshot monitoring (/SDF/SMON; NetWeaver 7.4 and higher)

Why are these important?

How do I check for them?

How do I x them?

Who can help if I encounter a problem?

6. Active Session History and Automatic Workload Repository (Oracle 10g+ and higher)

Why are these important?

How do I check for them?

How do I x them?

Who can help if I encounter a problem?

7. Statistic Server and _SYS_STATISTICS schema (HANA only)

Why are these important?

How do I check for them?

How do I x them?

Who can help if I encounter a problem?

8. Retention periods

A. STAT les

B. ST03 aggregates

C. SMON snapshot collections

D. Oracle AWR

E. HANA Statistics Server

Summary

1. Software components ST-PI and ST-A/PI

Why are these important?

These software components are plug-ins which contain a number of service tools including transactions ST12 and /SDF/SMON. These tools
are mandatory in many performance problem scenarios. They are also required if any CQC services are to be delivered for a system.

How do I check for them?

Open transaction ST13 and execute the RTCCTOOL tool; the tool will check SAP servers for newer versions of these components and
recommend updating them if needed.
(If your system does not contain ST13 then that system is missing ST-A/PI altogether.)

How do I x them?

The following SAP Notes explain how to install and update ST-PI and ST-A/PI software components:
539977 - Release strategy for add-on ST-PI
69455 - Servicetools for Applications ST-A/PI (ST14, RTCCTOOL, ST12)

Installing and updating ST-PI and ST-A/PI can be done while the system is running and does not require downtime.

Who can help if I encounter a problem?

If you are having trouble installing these software components, please contact SAP support in component BC-UPG-OCS.

This is custom documentation. For more information, please visit the SAP Help Portal 47
 9/2/2024

2. STAT les (STAD)

Why are these important?

STAT les form the basis of performance analysis. They contain statistic records for individual dialog steps and are used by the monitoring
framework to create workload data (ST03).

How do I check for them?

STAT les are located in the DIR_DATA directory and are named statnnnn ("stat" with several digits following).
Check for these les using transaction AL11 and opening the DIR_DATA directory. Make sure their Lastchange timestamps are up to date. (1
le every hour for the past 48 hours.)

How do I x them?

If they are missing in a system, or if the timestamps are not recent, check the parameter stat/level using transaction RZ11, it should be set to
1 (one).

Who can help if I encounter a problem?

If these les are still missing, please contact SAP support in component BC-CST-ST.

3. Workload Monitor (ST03) data

Why are these important?

Transaction ST03 is used to browse workload data which is used to identify problem time periods and provides a rst look at which response
time types might be responsible for a performance problem.

How do I check for them?

If there is no workload data, then opening ST03 will display the following message:

If there is workload data, make sure it is up to date by checking the date of the most recent daily aggregate:

This is custom documentation. For more information, please visit the SAP Help Portal 48
 9/2/2024

How do I x them?

Missing and outdated workload data is corrected in almost all cases by one of the points in SAP Note 2369736 - Troubleshooting missing data
in ST03N/ST03.

The most common cause of this missing data is a time zone inconsistency between client 000 and the operating system.

Additionally, in order for workload data to exist, the system must be generating STAT les as mentioned above.

Who can help if I encounter a problem?

If workload data is still missing after referring to the above SAP Note, please contact SAP support in component BC-CCM-MON-TUN.

4. OS Monitor (ST06) data

Why are these important?

Transaction is used to browse operating system data such as CPU and memory consumption. If the performance problem is rooted in a
resource bottleneck, then the historical data in ST06 is valuable.

The most important KPIs are:

Snapshot

Previous Hours → CPU

Previous Hours → Memory

History → CPU

History → Memory

Additional Functions → Hardware information

How do I check for them?

Open transaction ST06 and click on the KPIs mentioned above:

This is custom documentation. For more information, please visit the SAP Help Portal 49
 9/2/2024

If they are missing, there will be an empty table:

How do I x them?

To x missing data, refer to SAP Note 1915341 - No History Data in ST06 / OS07N

In a nutshell:

A. Ensure time zones in the system are con gured correctly per SAP Note 1937227 - Missing history data in ST06

If Previous Hours are missing:

B. Check SAP Notes 2338673 and 1697515 for inconsistencies in transaction RZ20.

If History is missing:

C. Make sure Previous Hours are not missing

D. Check the Central Performance History (CPH) con guration via transaction RZ23N → Assign Procedure and make sure the CPU* and
Memory* MTE Classes are assigned to the desired system. If they are not, assign the CPU* and Memory* classes per SAP Note 1147334
- CPH setup for OS data.

This is custom documentation. For more information, please visit the SAP Help Portal 50
 9/2/2024
Once the MTE classes are added, wait 24 hours to see if the previous day's data appear in History .

Who can help if I encounter a problem?

If all of the above is done, and data is still missing, please contact SAP Support in component BC-CCM-MON-OS.

5. Daily snapshot monitoring (/SDF/SMON; NetWeaver 7.4 and higher)

Why are these important?

Snapshot monitoring is used to periodically collect KPIs. These KPIs include WP tables, CPU and Memory consumption. The WP tables are
extremely helpful in understanding the activity of the system over time.

Turning on SMON is the most common request made by SAP Support in performance-related incidents, but it is only helpful if the collectors
are running during the performance problem.

How do I check for them?

To see if SMON Daily Monitoring is turned on, open transaction /n/sdf/smon ("/n" is needed or else "/sdf/mon" will be interpreted as a
function code) and click the Schedule New Monitoring (F6) button. If Daily Monitoring is turned on, you will see the Change Daily Monitoring
(Ctrl+F2) and Stop Daily Monitoring (Ctrl+F3) buttons:

You should also see up to date snapshot collections by clicking Show Analyses (Ctrl+F1).

(In this screenshot, the cog icon in the Status column also indicates there are collectors running)

How do I x them?

To enable SMON Daily Monitoring, follow the steps in SAP Note 2651881 - How to con gure SMON for performance monitoring and analysis.

It is recommended to keep SMON Daily Monitoring turned on permanently; the resource requirements of the SMON collectors are negligible
and can safely be run in production systems.

SMON is only available in NetWeaver Releases 7.4 or higher. For older releases of NetWeaver, please use /SDF/MON:
2383809 - How to con gure /SDF/MON for performance monitoring and analysis

Who can help if I encounter a problem?

If you encounter problems turning on SMON or with SMON itself, please contact SAP support in component SV-SMG-SDD.

6. Active Session History and Automatic Workload Repository (Oracle 10g+ and higher)
Why are these important?

If SAP Support nds the performance problem to be manifesting as increased DB response time, then access to ASH and AWR data is needed
to determine the type of wait events causing the increased DB time.
(SAP Note 853576 - Oracle 10g: Performance analysis w/ ASH and Oracle Advisors further explains the bene ts of ASH and AWR.)

How do I check for them?

To see the time period covered by ASH and AWR data, execute the following queries respectively:

This is custom documentation. For more information, please visit the SAP Help Portal 51
 9/2/2024

SELECT
TO_CHAR(MIN(SAMPLE_TIME), 'YYYYMMDD;HH24MISSFF3') MIN_SAMPLE_TIME,
TO_CHAR(MAX(SAMPLE_TIME), 'YYYYMMDD;HH24MISSFF3') MAX_SAMPLE_TIME
FROM
gv$active_session_history;

SELECT
TO_CHAR(MIN(SAMPLE_TIME), 'YYYYMMDD;HH24MISSFF3') MIN_SAMPLE_TIME,
TO_CHAR(MAX(SAMPLE_TIME), 'YYYYMMDD;HH24MISSFF3') MAX_SAMPLE_TIME
FROM
DBA_HIST_ACTIVE_SESS_HISTORY;

Copy this code!

The results should be up to date.

How do I x them?

No con guration typically is needed to collect ASH and AWR data, they should be automatically collected by default.

However, in order for SAP Support to query the data in these tables from DBACOCKPIT, the following authorization object and elds are
required:

Authorization object: S_TABU_SQL

elds:
ACTVT = 33
DBSID = *
TABLE = *
TABOWNER = SYS

(If the system is not on SAP_BASIS release 702SP11, 730SP7, 731SP3, or higher, then the authorization concept is different; in this case refer
to SAP Note 1755304 - Authorization problems with Oracle SQL command editor.)

Who can help if I encounter a problem?

If there are no results or the results are outdated, contact SAP Support in component BC-DB-ORA.

7. Statistic Server and _SYS_STATISTICS schema (HANA only)

Why are these important?

Like the point above, if SAP Support nds the performance problem to be manifesting as increased DB response time and the DB in question
is HANA, then access to the SYS_STATISTICS. schema is needed.

How do I check for them?

To ensure the collectors are running and the data in _SYS_STATISTICS are up to date, download and extract the attachment in SAP
Note 1969700 , nd and execute the statement HANA_StatisticsServer_Histories_RetentionTime<version>.txt.

The STATUS column should not contain Inactive and the OLDEST_DATA_DAYS should not be blank or signi cantly greater than
CUR_RET_DAYS.

How do I x them?

If STATUS contains Inactive for one of the collectors, refer to point 11 in SAP Note 2147247 - FAQ: SAP HANA Statistics Server for steps to
resolve this.

In order for SAP Support to query the data in these tables from DBACOCKPIT, the following authorization object and elds are required:

This is custom documentation. For more information, please visit the SAP Help Portal 52
 9/2/2024
Authorization object:
S_TABU_SQL
elds:
ACTVT = 33
DBSID = *
TABLE = *
TABOWNER = _SYS_STATISTICS

Who can help if I encounter a problem?

If there are issues with the HANA Statistics Server or the Inactive collectors cannot be corrected following the steps in the above Note,
contact SAP Support in component HAN-DB-MON.

8. Retention periods

Each of the above mentioned points have a particular retention time. Their respective retention times can be con gured to allow SAP
Support to look further backwards in time. This is helpful in that some incidents may not reach performance experts for many weeks, and
often the relevant historical data has already expired and been removed at this point.

The following gure demonstrates critical time periods based on default retention times:

If a performance problem occurs, this gure shows how long (by default) SAP Support has to analyze the relevant data. If performance
experts do not get to examine the system within these time periods, then that data is gone and cannot be used to determine root cause or
provide a solution.

In order to allow SAP Support longer periods of analysis (and in the event an incident does not reach performance experts right away), it is
recommended to increase these retention periods.

A. STAT les

The retention time of the STAT les are determined by parameter stat/max_ les. Each le contains 1 hour of records, therefore
setting stat/max_ les to 48 results in a retention time of 48 hours.

The allowable values of stat/max_ les are mentioned in SAP Note 2532788 - STAD parameter stat/max_ les values allowed.

Most Basis admins do not change this value, and 48 hours is sufficient in most situations. However, increasing stat/max_ les to a higher
value can be bene cial in cases where a performance problem might occur on a Friday or Saturday and performance experts are not available
to investigate until Monday.

B. ST03 aggregates

Workload data (ST03) retention times are con gured by following the steps in SAP Note 1843151 - ST03 Data Retention Time Settings.

This is custom documentation. For more information, please visit the SAP Help Portal 53
 9/2/2024
Adjust the retention times to the desired values. The size of the MONI table will grow to accommodate the increased retention times.

The default retention times are woefully inadequate and should be increased to a minimum of 14 daily, 8 weekly, and 4 monthly aggregates
in each workload area (including TOTAL). In other words, every row in the above table should contains minimum values of 14, 8, 4, 14, 8, 4, in
that order.

C. SMON snapshot collections

The default retention period of SMON collections is 14 days. To increase this retention period, Increase the value of Delete old analyses after
n days in the Daily Monitoring con guration screen.

14 days are usually sufficient. However, an incident will occasionally not reach performance experts in the rst 14 days. Increasing retention to
21 or even 28 days helps alleviate this problem. Systems which comfortably retain 30 days of snapshots are not unusual. If disk space in the
DB is a concern, monitor the growth of /SDF/* tables after increasing the retention period.

D. Oracle AWR

SAP Note 1326067 - Con gure retention period for Automatic Workload Repository explains how to con gure the retention period of the
AWR. The default is 7 days and the recommended is 42 days.

E. HANA Statistics Server

To con gure the retention period of the statistic tables, see point 15 in SAP Note 2147247 - FAQ: SAP HANA Statistics Server.

In newer releases of HANA, the retention time is already set to these default values, only in older releases do the retention times need to be
con gured.

Summary

The following table summarizes each checklist point above:

Checklist Item What needs to be done? SAP Notes/Articles/Parameters for con guration Where to get help Recommended
and troubleshooting Retention Period

1. ST-PI and ST- Install and Update 539977 - Release strategy for add-on ST-PI BC-UPG-OCS N/A
A/PI 69455 - Servicetools for Applications ST-A/PI

2. STAT les Ensure they exist in DIR_DATA parameters stat/level and stat/max_ les BC-CST-ST 48-72 hours
and are up to date by using
transaction code AL11

3. Workload data Ensure workload data exists by 2369736 - Troubleshooting missing data in BC-CCM-MON- Daily aggregates: 14+
(ST03) opening ST03 and also make sure ST03N/ST03 TUN Weekly aggregates:
it is up to date 1843151 - ST03 Data Retention Time Settings. 8+
Monthly aggregates:
4+

4. OS Monitor Ensure CPU and Memory data 1915341 - No History Data in ST06 / OS07N BC-CCM-MON-OS 45 days
data (ST06) exists in ST06 for Previous Hours 1147334 - CPH setup for OS data
and History

5. SMON Turn on SMON Daily Monitoring 2651881 - How to con gure SMON for SVG-SMG-SDD 21+ days
performance monitoring and analysis
All About SMON

6. Oracle AWR Con gure AWR retention period to 1326067 - Con gure retention period for BC-DB-ORA 42 days
42 days Automatic Workload Repository

7. HANA Statistics Con gure retention period to 42 2147247 - FAQ: SAP HANA Statistics Server HAN-DB-MON 42 days
Server days and ensure collectors are (unless otherwise
not Inactive speci ed by Note
2147247)

This is custom documentation. For more information, please visit the SAP Help Portal 54
 9/2/2024

Network Performance Analysis

This page will be introducing the troubleshooting guide and analysis tools when network performance is not optimal.
However network issue regarding to hardware/port/router/switch con gurations are beyond the scope of support. Customer needs to consult
their IT/Network team or vendor about further steps.

Typical Network Performance issue

The network performance should be diagnosed when the following symptoms occur.

Be aware these are only typical symptoms, are NOT a de nitive indication of a network performance issue.

High Roll-wait/GUI time showed in workload statistics(ST03/STAD)

High response time in LAN check by ping

High response time when performing RFC calls

Communication issue between SAP instance and Database instance

Network issues generally focus on problems with transmitting large data volumes or the speed at which the data is communicated. This can occur
due to the following:

Hardware issues

This can be wide ranging and can involve port issues (where the cable is connected), a router error (connects different networks), or a switch error
(connects different devices).

Poorly sized infrastructure

A network typically consists of multiple switches, routers and cables. For high volumes of data, the cables need to have available “bandwidth” to
efficiently transfer the data. For example, a cable with a bandwidth of 1Mb/s (known as Ethernet) will allow less data transfer than a 100Mb/s
cable (known as fast Ethernet).

Useful tools to identify network issues

NIPING

The NIPING Program can be used to diagnose the network or measure network metrics between any two machines running SAP software, for
example between:

Frontend PC and application server

Two application servers, perhaps belonging to different SAP systems

Application server and database server or live cache server

RFC server or client programs and application server

For self guided troubleshooting, please try our Guided Answer for Network analysis.

The NIPING result can be used to measure throughput and roundtrip time and perform stability test for LAN or WAN used.

Detailed information can be found in SAP Note 500235 - Network Diagnosis with NIPING.

Example commands:

For demonstration purposes the following example gives commands for a long LAN stability test;

On the client (source) side: niping -c -H your target server name here -B 10 -L 4000 -P -D 900
On the server (target side): niping -s -I 0 (the last character is zero, not the letter O)

So in the above case you have de ned the client (-c) and server (-s) commands and the duration of the NIPING trace (4000 loops with a delay of
900ms between each loop which will last for approximately 1 hour).

Example output:

The results from the output will be as follows;

This is custom documentation. For more information, please visit the SAP Help Portal 55
 9/2/2024
------- times -----
avg 4.695 ms
max 36.867 ms
min 0.658 ms
tr 12479.766 kB/s
av2 1.178 ms
tr2 49729.472 kB/s

The important values here are av2 and tr2.

av2: This will test your latency between machines, also known as round trip time. For a typical setup, a value of 0.7ms or less is considered a good
value although this can vary. If this value is higher, this may suggest communication delay issues between your systems.
tr2: The average throughput will display the real data volume capability of your system connections (as opposed to bandwidth which is ideal data
volume allowance). For example, if you have a 1GB connection and you are only getting throughput values of 100Mbps, this could suggest an
performance issue where high data transfers occur.

See more about NIPING output results in SAP Note 1100926 - FAQ: Network Performance.

Http Watch Trace

HttpWatch is a third-party browser plugin which can be used to trace the HTTP/HTTPS traffic between the browser and server triggered by each
action you take within a web application. It can be downloaded via http://www.httpwatch.com/download/.
This tool can be used to capture trace le for scenarios which having performance issue and get *.hwl les for further analysis.

1697063 - HttpWatch - Performance Analysis

1558903 - How To Trace a Portal Scenario Using HttpWatch

Sometimes, the root cause can be either Network, ABAP or a combination of both. In these cases it is recommended that you preform an ST12
trace along with a HTTP watch to determine where the issue is. This is noted here:

2424394 - Using HTTP trace and ST12 trace to diagnose slow response in customer portal

SAP GUI

The SAP GUI gets installed on the client side, typically within Windows. This allows access to the SAP system through the front end client side and
also assists with storing user preferences and logon details.

This communication between the SAP GUI and the backend SAP system can be the source of network related issues and slowness. Firstly, it is
recommended that you have the latest version of SAP GUI installed on your desktop.
See the below SAP Notes:

66971 - Supported SAP GUI platforms

1053737 - Expected release dates for SAP GUI for Windows

147519 - Maintenance strategy / deadlines for SAP GUI for Windows / SAP GUI for Java

Next to ensuring your GUI is within recommendations, a GUI performance trace should be performed to determine if the issue is on the GUI side or
the Network side, see in SAP Note 851012 - SAP GUI Performance trace

A performance issue will sometimes occur on the GUI side when the user preferences allow for population of the menu with large amounts of
information. This can be checked by trying the "low speed" connection setting within the GUI, see in SAP Note 161053 - Using SAP GUI in WAN.

Other helpful tools

Windows tools

TRACERT (WINDOWS) / TRACEROUTE (UNIX)

Useful for: Displaying the path and transit delays between source and destination on a network.

NETSTAT
Useful for: Viewing active TCP/UDP connections in real time.

NSLOOKUP
Useful for: Resolving domain names to IP addresses

This is custom documentation. For more information, please visit the SAP Help Portal 56
 9/2/2024
IPCONFIG (WINDOWS)
Useful for: Showing available connections on your Client side

Other tools

Wireshark
Useful for: Packet and network analysis on the OS side.

Graphing Niping output with RSORASTT

The RSORASTT tool can be used to graph NIPING outputs with the import option.

The tool can be found in SAP Note 1299493 - Loadable SAP Support Monitors

In order to graph your NIPING output, you need to run a "Long LAN stability test" where your Latency will be documented for a minimum of 1 hour.
This can then be imported into RSORASTT tool. This is very helpful for visualizing your Network latency over a long period of time.

Steps to graph NIPING results:

1. Collect Long LAN stability results

2. Save as plain text le

3. Open plain text le and use "select all" option

4. Copy and past output

5. In RSORASTT, choose "import clipboard" option

6. Name your server

Sample output:

Related SAP Notes and KBAs

203924 - SAP WAN Network settings

578118 - Long response times on the SAP GUI

161053 - Using SAP GUI in WAN

545136 - FAQ: Test tools for RFC connection

1139596 - SAP GUI: Connection to partner 'sapserver:sapdp00' broken

2443079 - Network performance analysis - LAN check by PING (OS01)

1227116 - Creating network traces

This is custom documentation. For more information, please visit the SAP Help Portal 57
 9/2/2024
1969914 - Packet scanning tutorial using wireshark

1370469 - How to perform a TCP trace with Wireshark

Performance Analysis SAP Notes and KBAs

Troubleshooting

2552474 - Performance Analysis: Guided Answers To Use

2436955 - Step by step instructions on how to use ST12 trace for analysis

2403517 - [WEBINAR] Interpreting traces collected with ST12

2442365 - Survival Guide for performance analysis on SAP system

948066 - Performance Analysis: Transactions to use

2399769 - General Performance: Troubleshooting Questions

2432675 - High Wait Time analysis in SAP system

2428353 - How to analyze high GUI time on SAP systems

2430181 - How To Analyze Work Process Performance Issues - Guided Answers

Performance Tools

755977 - ST12 "ABAP Trace for SAP EarlyWatch/GoingLive"

2169881 - How to trace background job using ST12

1558903 - How To Trace a Portal Scenario Using HttpWatch

1817693 - How to trace the ITS Service "WEBGUI" directly using HttpWatch?

1697063 - HttpWatch - Performance Analysis

2126913 - ENQU: The enqueue log

2383809 - How to use the SDF/MON tool to analyse performance issues

1817724 - How to create HttpWatch trace to troubleshoot BSP related problems

2255214 - Analyze CRM UI performance issues on backend using STAD

1608474 - Recording end-to-end traces for root cause analysis

2879724 - How to analyze performance traces with the pro le data analyzer

Database Performance

332677 - Rebuilding fragmented indexes

1171650 - Automated Oracle DB parameter check

2087573 - Roadmap for performance problem analysis

1732157 - Collecting diagnosis information for SAP HANA [VIDEO]

1817553 - Checklist for performance problems in SAP Oracle Databases

2186006 - DB6: How to match an SAP work process with database application handle [VIDEO]

Network Performance

1100926 - FAQ: Network Performance

500235 - Network Diagnosis with NIPING

Other Relevant Performance Analysis Notes

8963 - De nition of SAP response time/processing time/CPU time

1395160 - Priority de nition of SAP incidents - EPM

162991 - Generation tools for ABAP programs SGEN

2085980 - New features in memory management as of Kernel Release 7.40

This is custom documentation. For more information, please visit the SAP Help Portal 58
 9/2/2024
2430134 - decision tree - How to Determine Which Component a Performance Issue Belongs to

Performance Analysis Transactions and Tools

For an overview for transactions used in performance analysis, read SAP Note 48066 - Performance Analysis: Transactions to use

Workload Monitoring - ST03/ST03N

Expert Content What to Monitor in ST03/ST03N

SAP Help Page Workload Monitor

Snapshot Monitoring - SMON

SMON allows for the periodic collection of performance data such as CPU utilization, memory, work process utilization and samples, request
queue lengths, and more.
Learn how to con gure and schedule SMON, read SAP Note 2651881 - How to con gure SMON for performance monitoring and analysis.

For other information related to SMON, check Expert Content Page All About SMON.

SMON replaces the older snapshot tool /SDF/MON. We recommend using SMON when possible.
For information on /SDF/MON see SAP Note 2383809 - How to use the SDF/MON tool to analyse performance issues.

ABAP Performance Trace - ST12

Expert Content Page ABAP and Performance Trace

KBA 2436955 - How to collect and analyze traces using ST12 (single transaction analysis)

ST05

Expert Content Page How to run transaction st05 to trace a program, transaction or user execution

KBA 2482775 - Optimizing Expensive SQL Statements - Guided Answers

STAD - Business Transaction Analysis

Expert Content Page STAD - ABAP Business Transaction Analysis

SAP Note 552845 - FAQ: RFC Statistics in Transactions ST03/ST03N and STAD

SAP Note 8963 - De nition of SAP response time/processing time/CPU time

SE30 and SAT

Expert Content Page ABAP Runtime Analysis

KBA 2327539 - How to create a SE30 Trace for Web Dynpro ABAP Application [VIDEO]

Other useful tools and References

Kernel Snapshot

The snapshots in the ABAP server aim to display important information about the current situation of the server.

Expert Content Page:Snapshots in the SAP System

KBA 2640476 - How to analyze Server Snapshot with kernel snapshot analyzer

HTTP Watch Tool

Download HTTP Watch here

HTTPWatch Help

SAP Note 2524696 - How to save HttpWatch traces automatically

This is custom documentation. For more information, please visit the SAP Help Portal 59
 9/2/2024
DPMON Tool

Related SAP Note: 42074 - Using the R/3 dispatcher monitor 'dpmon'

Expert Content Page DPMON Dispatcher Monitor

Tracing load balancing

SAP Note 64015 - Test programs for load balancing

SAP Note 1385815 - Tracing load balancing

End-to-End Trace (E2E)

Problem Detection by End-to-End (E2E) Trace Analysis

RSMEMORY: SAP Note 177226 - Documentation rsmemory

SAP Help Page The rsmemory Report

Pro le Data Analyzer

There is a standalone tool to systematically analyze issues from pro ling data les. Read Expert Content Page Pro le Data Analyzer - A Tool to
Analyze the Performance Traces for Both ABAP and Java

All about SMON

Purpose
The purpose of this Wiki page is to provide general information on the Snapshot MONitoring utility in report /SDF/SMON (hence referred to as
SMON).

Purpose

General

Installing SMON

How to Schedule SMON

Navigating SMON

Timeframe, Interval, & Server

Timeframe

Servers

Interval and Every nth time

Content Collected by SMON

1. Time since last measurement in ms

2. List of workprocesses (SM50)

3. Create Call Stack

4. Dispatcher Queue

5. Extended and Heap Memory

6. Number of logins/sessions

7. Memory per modes

8. CPU and paging activity

9. Top CPU Processes

10. Enqueue entries ‡

11. Enqueue statistics

12. Inbound queues ‡

13. Outbound queues ‡

Differences Between SMON and /SDF/MON

CPU and paging activity

This is custom documentation. For more information, please visit the SAP Help Portal 60
 9/2/2024
Inclusion of Logon handles and Session IDs

Additional features in WP lists

Call Stack generation

Storage method

WP sample aggregation

Tables Used by SMON

SMON Overhead and Space Requirements

Locks Used by SMON

Deleting Large Snapshot Collections (Timeframe > 24 hours)

General

SMON is a monitoring utility that periodically collects data related to the system's health.

SMON is the successor to /SDF/MON and collects additional data and contains features which /SDF/MON does not.

It is recommended to use SMON instead of /SDF/MON.

SMON works by starting long-running collectors, one per application server. These collectors sleep (WAIT UP TO ...) between snapshots and are
started as RFC calls in an "async w/o result" connection.

Collected snapshots are stored in Snapshot Collections.

Customers sometimes express concern over these long-running collector tasks thinking their system has a performance problem, but the behavior
is expected and not an indication of a performance problem; see SAP Note 2229255 - Long RFC response times when you use /SDF/MON.

Installing SMON

SMON is rst made available in SAP NETWEAVER 7.4

The system must have Software Component ST-PI Release 740 with SP-Level 0002 or higher.

Refer to SAP Note 539977 for steps on installing & updating ST-PI.

In lower SAP NETWEAVER releases where SMON is not available, /SDF/MON can be used as an alternative ( SAP Note 2383809 )

How to Schedule SMON

See SAP Note 2651881 - How to con gure SMON for performance monitoring and analysis.

Navigating SMON

To access SMON, execute transaction /n/SDF/SMON (a leading "/n" is required due to the namespace) or run report /SDF/SMON in transaction
SE38.

If no snapshot collections exist yet in the system, the home screen of SMON will be the Start Snapshot Monitoring screen:

This is custom documentation. For more information, please visit the SAP Help Portal 61
 9/2/2024

If collections do exist in the system, the home screen with be the Snapshot Monitor screen, listing these collections:

Double clicking a snapshot collection (or selecting a collection and clicking the Display Overview Data button) will display the Filter dialog screen:

This is custom documentation. For more information, please visit the SAP Help Portal 62
 9/2/2024

This allows initial ltering to be done prior to viewing the snapshots and is useful if you know the timeframe the problem occurred or if the issue
was isolated to an application server/user/WP type/etc.

Because the default interval of SMON is 1 second (and since most content is only collected every 10th or 60th interval) the default restriction is to
display every 30th snapshot.

If you would like to see every snapshot change the Display only every nth snapshot value to 1.

There is an issue when using the Display only every nth snapshot restriction.

When trying to display the additional content (e.g. Memory per mode) in the Monitoring Data overview screen, SMON will sometimes raise a "No
detailed information available" error message.

This can occur when content which is collected every n snapshots, and the snapshots being displayed via the display only every option are not the
same.

For example, if we are only viewing snapshots ending in :13 (hh:mm:13; display only every set to 60) and the Top CPU Processes (collected every
60th snapshot) were collected on snapshots ending in :00 (hh:mm:00) then SMON may raise the error previously mentioned when trying to
display that content.

Clicking Execute on the snapshot lter dialog screen will take you to the overview data for the snapshot collection. Each row in the Monitoring Data
table corresponds to a single snapshot.

For content which is collected Every n times (e.g. CPU and paging activity) the information is repeated in the rows following the snapshot in which
it was collected until the next nth snapshot.

This is custom documentation. For more information, please visit the SAP Help Portal 63
 9/2/2024

Timeframe, Interval, & Server

When con guring snapshot monitoring, the timeframe, interval, and servers options de nes the scope and collection rate of the content.

Do NOT con gure a timeframe greater than 24 hours.

SMON is not designed to gracefully handle multiple days of data in a single snapshot collection.

If more than 24 hours of monitoring is needed, use Daily Monitoring instead.

If for some reason there is a snapshot collection which covers a timeframe greater than 24 hours, see deleting large snapshot collections for steps
to remove them safely.

Timeframe

Determines when the SMON collectors should start and end. The option [Do not delete before] determines the expiration date of the
snapshot collection. When this date is reached the collection is automatically deleted.

When con guring Daily Monitoring, only the start and end time may be de ned and the expiration date is de ned by the age of the collection
rather than a speci c date:

Servers

De nes the application servers which the collectors will be started on. If left blank, collectors will be started on all application servers.

Interval and Every nth time

[Interval in seconds] de nes the base interval for how often the collectors roll-in to generate a snapshot.

[Every n times] de nes how often that content will be collected as a multiple of [Interval in seconds].

In the screenshot above, "List of workprocesses (SM50)" is collected every 5 seconds, but "Dispatcher queue" data are only collected once
every 30 seconds.

This is custom documentation. For more information, please visit the SAP Help Portal 64
 9/2/2024
[List of workprocesses (SM50) interval] = [Interval in seconds] * [List of workprocesses (SM50) Every n times] = 5 seconds * 1 = 5
seconds

[Dispatcher queue interval] = [Interval in seconds] * [Dispatcher queue Every n times] = 5 seconds * 6 = 30 seconds

As [Interval in seconds] is increased, [Every n times] should be reduced by a similar factor to avoid large gaps between snapshots.

Content Collected by SMON

Whether con guring one-time monitoring or Daily Monitoring, the content options are the same:

When browsing the collected data, the content switches above correspond to the columns below:

Some information must be accessed through the Goto menu or by double-clicking particular columns.

This is custom documentation. For more information, please visit the SAP Help Portal 65
 9/2/2024

1. Time since last measurement in ms

The time elapsed since the last snapshot on that application server.

The color of the snapshot will be highlighted:

Yellow when: [time since last measurement] - [Interval in seconds] > 1 second

Red when: [time since last measurement] - [Interval in seconds] > 5 seconds

"Time since last measurement" is useful for nding periods where request processing may have been disrupted.

Every "Interval in seconds", SMON collectors need to roll in to collect content and generate a snapshot.

If something* delays the roll-in or the collector itself, "time since last measurement" will be signi cantly greater than "interval in seconds".

(*Many general performance problems can cause delays in the collectors. This something could be: no free WP is available, CPU bottlenecks,
memory thrashing, slow/hanged DB commits, and much more.)

To nd snapshots that have been delayed, use the "Min. Delay in seconds" eld on the Filter screen:

2. List of workprocesses (SM50)

The Work Process activity on each application server; similar to the information found in SM50 and with the dpmon tool.

In addition to collecting the Work Process activity, SMON contains tools for analyzing the collected WP data:

Work Process List - Displays all WP samples in the selected snapshots/rows.

Filtered WP List - As above, will display WP samples from all selected snapshots with the option of including lter criteria

WP List Aggregation - Allows you to aggregate WP samples by common criteria. Optionally allows you to apply lter criteria at the
same time.

3. Create Call Stack

When enabled, the collectors will attempt to obtain the ABAP call stacks of running WPs.

A call stack is not always obtained depending on the current activity & state of the WP.

When a call stack for a WP sample is available, there is a eld in the WP list called Stack Info Available that will contain a call stack icon:

Double clicking the call stack icon will display the call stack:

This is custom documentation. For more information, please visit the SAP Help Portal 66
 9/2/2024

4. Dispatcher Queue

The queue length information for DIA, UPD, and ENQ task types on each application server.

Similar to the information found in SM51 → Goto → Information → Queue Information.

Helpful for nding periods with high workload/wait times.

5. Extended and Heap Memory

The roll+heap memory use from NetWeaver's perspective.

6. Number of logins/sessions

Useful for estimating workload.

7. Memory per modes

Similar to the information found in SM04. Information about each logon and the memory used by each user mode/session.

8. CPU and paging activity

Same information found in ST06 (OS monitor). ST06 only provides current and hourly values, SMON collects this information in more
granular time intervals (down to 60 seconds).

Useful for ensuring the SAP system is provided enough memory and is receiving enough resources from the hypervisor.

9. Top CPU Processes

Same information as found in ST06 → Snapshot → Top 40 CPU processes.

Useful for checking if non-SAP processes are competing with the NetWeaver system for CPU resources.

10. Enqueue entries ‡

Same information as in SM12 → List.

11. Enqueue statistics

Same information as in SM12 → Extras → statistics.

12. Inbound queues ‡

The same information which can be browsed in SMQ2 (Inbound Queue monitor).

This information is not very useful as it is not easy nor possible in some cases to link a blocked/long-running queue to a particular action/WP
in the snapshots.

The same problem exists when investigating a qRFC problem live in the system, as such, root cause analysis of historical qRFC issues (which
are not attributed to general performance) is not possible in some cases.

This is custom documentation. For more information, please visit the SAP Help Portal 67
 9/2/2024

13. Outbound queues ‡

The same information which can be browsed in SMQ1 (Outbound Queue monitor).

As mentioned above, this information is not very useful and historical qRFC investigation is limited.

‡ : May cause a high workload; see Overhead and Space Requirements

Differences Between SMON and /SDF/MON

Below lists some of the key differences between SMON and /SDF/MON and reasons why SMON should be chosen over /SDF/MON.

CPU and paging activity

SMON includes much more information from the OS collector (ST06 data) and in some cases critical information for understanding the
resource consumption (including KPIs of virtualized servers) during that time frame which is not recorded anywhere else in that granularity.

SMON:

/SDF/MON:

It's easy to see how much more valuable SMON is by simply including virtualization KPIs such as CPUs consumed, CPU Ready, and Steal time.
Note how misleading the Free Memory column of /SDF/MON is when the le system cache is not considered!

Inclusion of Logon handles and Session IDs

SMON includes the back-end session key used to uniquely identify each session (user mode) in the system, /SDFMON does not. This allows
us to pro le and track dialog steps across roll-outs and roll-ins when the user session does not roll back into the same WP (i.e. the WP
number changes).

In the screenshot below is the WP list of a snapshot and another screen of SM04 → User → Technical Information.

The back-end session key is included in the form of the Logon Key , Logon ID, and Back-end Session Handle and is also included in the
Memory per modes (SM04) snapshots.

Additional features in WP lists

When viewing a WP list, there are additional functions/buttons in SMON which are not present in /SDF/MON:

This is custom documentation. For more information, please visit the SAP Help Portal 68
 9/2/2024

1. Statistical record (F9)

Selecting a row from the WP table and clicking this button takes you directly to transaction STAD and displays the STAT record (if it still
exists) of the dialog step corresponding to the selected WP sample.

2. Show entries of the same dialog step

Selecting a row from the WP table and clicking this button will display all WP samples from that dialog step:

3. ABAP Workbench

Selecting a row from the WP table and clicking this button will display the program captured in the sample in the ABAP Workbench.
Additionally, if a call stack is present for the selected sample the Workbench will open on the line of code recorded in the call stack.

Call Stack generation

Simply, /SDF/MON does not generate call stacks for WP samples.

Storage method

SMON stores the majority of its snapshot data transparently; contrast this with /SDF/MON which stores snapshot data as per SAP Help
Page Data Clusters.

This allows us to query much of the data directly with SQL when more granular control over ltering or aggregation is required.

WP sample aggregation

SMON contains functions for aggregating WP samples. This allows us to identify trends in WP behavior (e.g. estimating what percent of
runtime was spent waiting for DB commits).

While /SDF/MON appears to contain the same functionality, it does not seem to be implemented or is bugged; I have never been successful
in using the WP aggregation function in /SDF/MON.

Tables Used by SMON

SMON uses many tables. Some tables contain administration/con guration data needed to run SMON; other tables store the snapshot data,
aka SMON's "payload".

This is custom documentation. For more information, please visit the SAP Help Portal 69
 9/2/2024
All tables are transparent-type tables per the ABAP dictionary (SE11), but some tables contain data clusters.

When the Storage Method is Direct, the data can be queried directly with SQL.

When the Storage Method is Data cluster then data in that table is stored as a data cluster and cannot be queried directly with SQL.

Table Name Storage Data stored Comments

Method is...

/SDF/SMON Data cluster Snapshot Data such as Top 40 CPU Processes and Enqueue entries

/SDF/SMON_CLUST Data cluster Admin/Con g Clustered/compressed snapshot data to reduce storage size

/SDF/SMON_CALL Direct Admin/Con g Information needed to start the collectors via RFC

/SDF/SMON_CALLPA Data cluster Admin/Con g Information needed to start the collectors via RFC

/SDF/SMON_HEADER Direct Snapshot Header data for each snapshot as seen in the Monitoring Data
screen. E.g. CPU & Memory Consumption, Active WPs, EM
allocated/free

/SDF/SMON_LAYOUT Data cluster Admin/Con g ALV grid/table layouts for viewing SMON data (in other words, what
columns you see in the Monitoring Data table)

/SDF/SMON_RUN Direct Admin/Con g Header information for each snapshot collection such as the content
that is being collected and if the collection is currently
clustered/compressed

/SDF/SMON_SESS Direct Snapshot Contains session information (SM04); "Memory per modes" content
type

/SDF/SMON_STACK Direct Snapshot Collected stack trace samples

/SDF/SMON_STACKD

/SDF/SMON_STACKH

/SDF/SMON_WPINFO Direct Snapshot Snapshots of WP samples

SMON Overhead and Space Requirements

The CPU and memory requirements of SMON are mostly negligible and SMON can safely be run in production environments.

The only content for which collecting may place a non-negligible load on that part of the system are:

Enqueue entries

Inbound queues

Outbound queues

However, when the above content is enabled, there will be an explicit warning.

For example, turning on "Enqueue entries" will display the following message:

For day to day monitoring, Enqueue entries, Inbound queues, and Outbound queues are not needed.

Space requirements should not be a concern due to the abundance of storage space in this day and age.

If storage space truly is a concern, the tables mentioned in the previous section can be monitored and if the size on disk of these tables is
unacceptable, the [Interval in seconds] can be increased to reduce the volume of data collected.

Keep in mind that larger [Interval in seconds] will make analysis of short-lived performance problems more difficult.

Locks Used by SMON

This is custom documentation. For more information, please visit the SAP Help Portal 70
 9/2/2024
It's normal to see long-lasting locks in SM12/SMENQ created by SMON.

When SMON collectors are started, they will obtains locks on the /SDF/SMON_CALL_KEY table. There will be 1 lock per application server
(and one additional lock if one of the Global Content switches are enabled)

The SMON watchdog (job /SDF/SMON_WATCHDOG) which runs every 5 minutes checks the enqueue table for these locks.

If the locks are missing, it usually means the collectors are no longer running and the watchdog will restart the collectors.

For more information about these locks, see SAP Note 2689689 - /sdf/mon or /sdf/smon related locks remain in SM12

Deleting Large Snapshot Collections (Timeframe > 24 hours)

If for some reason a single snapshot collection covers more than 24 hours, do NOT immediately use the Delete button to remove it.

SMON tries to delete all records in /SDF/SMON_WPINFO that belong to a particular snapshot collection in a single DB transaction. SMON
does not periodically commit during the delete.

As a result, if a particular snapshot collection contains an extremely large amount of data, trying to delete it directly may result in the DB's
log buffers lling completely and preventing any transactions from being processed.

To avoid this problem:

1. Truncate /SDF/SMON_WPINFO and /SDF/SMON_HEADER (the data in these tables are not system-critical)

2. Then use the Delete button to remove the snapshot collection

All snapshots from all collections will be lost, but this prevents a possible log buffer full situation.

Pro le Data Analyzer - A Tool to Analyze the Performance Traces for Both ABAP and Java

Purpose

The purpose of this Wiki page is to summarize the resources and tips for pro le data analyzer which is a standalone tool to systematically analyze
issues from pro ling data les (pro ling les from SAP JVM Pro ler or ABAP Runtime Analysis) and create analysis reports. These analysis reports
can be used by application developers, system administrators, and support engineers to easily identify the most expensive parts of a program and
optimize them accordingly.

Purpose

Typical Scenarios

Download Link

Getting Started

Further Reading

Support & Feedback

Typical Scenarios
Here are the typical scenarios for the pro le data analyzer.

Visualize ABAP Runtime Analysis or SAP JVM Pro ler pro ling les as interactive and intuitive Flame Graphs,

Graphically compare performance traces in order to e.g. to understand a performance degradation after implementing a Support Package,

Convert ABAP Runtime Analysis les into the SAP JVM Pro ler format to make use of advanced pro ling features of SAP JVM Pro ler

Download Link
This is custom documentation. For more information, please visit the SAP Help Portal 71
 9/2/2024
The download link is documented in KBA 2879724. Here is the direct download link in SAP Portal Page. It can also be downloaded from the following
link by searching "pro le data analyzer".

Get Started with Free Trials and Downloads

The latest version is "pro le data analyzer 1.0.20210222".

Getting Started
The following SAP Blog contains a getting started guide for pro le data analyzer. When you download the package, you will also nd a PDF guide
named "Pro le_Data_Analyzer.pdf" together with the executable java le.

Analyze ABAP Performance Traces with the Pro le Data Analyzer

Understanding the ABAP Program Logic With Pro le Data Analyzer for Performance Optimization and Other Tasks

Understanding the ABAP Program Logic With Pro le Data Analyzer – ME23N

As shown in the above blog posts, the performance ame graph is one of the most interesting parts in the analysis report of pro le data analyzer.

Here is a ame graph example and the tips about how to read the performance ame graph.

Every column is a call stack. The main program is at the bottom. The lower method calls the upper method.

The width in the graph is proportional to the actual time used by that call stack.

We could zoom in or zoom out in the graphic view by clicking a method on the call stack.

Click the "Search" button to search with regular expressions. The search results will be highlighted in purple.

Move the mouse to a method, the tooltip will show more detailed time information.

Special method types have dedicated colors. For example, DB methods are blue.

The call count of a call stack is shown like "Calls: XXX" on top of the call stack.

Further Reading

The changes for pro le data analyzer will be tracked on the below SAP Blog post.

Changes for Pro le Data Analyzer

Here are the KBAs for the pro le data analyzer, including how to collect the trace and how to analyze it with pro le data analyzer.

KBA 2946611 - Pro le Data Analyzer: Central KBA

Guides & References

KBA 2879724 - How to analyze performance traces with the pro le data analyzer

KBA 2881237 - How to collect performance trace for the pro le data analyzer

KBA 2891307 - How to convert ABAP trace by pro le data analyzer and analyze it with SAP JVM Pro ler
This is custom documentation. For more information, please visit the SAP Help Portal 72
 9/2/2024
Tips

KBA 2946431 – The searching tips in pro le data analyzer

KBA 2946441 – The color legend in pro le data analyzer

KBA 2948335 – The frequently-used pro le data analyzer options for ABAP trace

KBA 2916386 – Check pro le data analyzer call position in the backend system

Here are the documents for SE30, SAT and ABAP performance trace

SAP Help Page Executing Measurements in SE30/SAT

SAP Help Page Starting the ABAP Pro ler on ABAP in Eclipse

Aggregation by call stack which could reduce the trace size and only available on ABAP in Eclipse, see in SAP Help Page Understanding
ABAP Pro ler Settings

Here are the documents for the SAP JVM Pro ler. To lever the full potential of the SAP JVM Pro ler, we suggest going through the following SAP
JVM Pro ler documentation.

Expert Content Page Java Pro ling

Support & Feedback

Your feedback is appreciated and needed. We are looking forward to your feedback. But the support channel of the pro le data analyzer is not the
OSS incident in the SV-PERF component. If you have any feedback or any issue while using the pro le data analyzer, please feel free to send an
email to "qiansheng.wang AT sap.com" or post a comment in the following SAP Blog post. We will follow up with you there.

Analyze ABAP Performance Traces with the Pro le Data Analyzer

What to Monitor in ST03/ST03N?

What are the things we have to monitor in ST03 (Workload Analysis Monitor) and what should be the range (ie time in ms)?

System statistics are written to the R/3 kernel and can be displayed using the workload monitor (Transaction ST03N). They provide system
administrators with varied and detailed information on CPU time, numbers of database changes, roll out times and so on.

Overview of This Page

Average CPU time used in the work process

Average response time

Average wait time

Average load time

GUI time

Roll ins

Roll outs

Roll in time

Roll out time

Roll wait time

Database calls

Database requests

Average time per logical DB call

Performance Data Time

Database Requests Time

This is custom documentation. For more information, please visit the SAP Help Portal 73
 9/2/2024
High Values for Reason

Most Important Workload Statistics

Average CPU time used in the work process

During a dialog step, the CPU of the application server is used for processing (loading, generating, database request processing, ABAP
processing and so on). The CPU time is determined by the operating system. At the end of a transaction step, the R/3 work process queries
the CPU time from the operating system. The CPU time is therefore not an additive component of the response time, unlike the wait, roll-in,
load and database time.

Average response time

The average response time of a dialog step is the average time measured from the time a dialog sends a request to the dispatcher work
process through the processing of the dialog up to the time the dialog is completed and the data is passed to the presentation layer. The
response time between the SAP GUI and the dispatcher is not included in this value.

The response time does NOT include the time taken to transfer data from the R/3 frontend to the application server. For networks with low
performance, this can create a highly subjective response time. The transfer time is contained in the GUI network time.

Response time is usually split into wait time plus dispatch time. The SAP response time is composed of the following components:

- Response time = wait time + dispatched time

- Dispatched time = Generation time during runtime

- Load time for programs, screens and CUA interfaces

- Roll times to roll-in work data

- ABAP processing time

- Database time

- Enqueue time for logical SAP lock procedures

- CPIC/RFC time

- Roll wait time (apart from task types RFC/CPIC/ALE).

The CPU time is not an additive component of the response time, but the sum of the CPU time that is used by the individual components. The
CPU time therefore provides additional, independent information on the response time.

Average wait time

The time an unprocessed dialog step waits in the dispatcher queue for a free work process. Under normal conditions, the dispatcher work
process should pass a dialog step to the application process immediately after receiving the request from the dialog step. Under these
conditions, the average wait time would be a few milliseconds. A heavy load on the application server or on the entire system causes queues at
the dispatcher queue.

Average load time

The time needed to load and generate objects such as ABAP source code and screen information from the database.
Database calls - The number of parsed requests sent to the database.

GUI time

The GUI time is measured in the work process and is the response time between the dispatcher and the GUI.

Roll ins

Number of rolled-in user contexts.

Roll outs

This is custom documentation. For more information, please visit the SAP Help Portal 74
 9/2/2024
Number of rolled-out user contexts.

Roll in time

Processing time for roll ins.

Roll out time

Processing time for roll outs.

Roll wait time

Queue time in the roll area. When synchronous RFCs are called, the work process executes a roll out and may have to wait for the end of the
RFC in the roll area, even if the dialog step is not yet completed. In the roll area, RFC server programs can also wait for other RFCs sent to
them.

Database calls

The number of parsed requests sent to the database.

Database requests

The number of logical ABAP requests for data in the database. These requests are passed through the R/3 database interface and parsed into
individual database calls. The proportion of database calls to database requests is important. If access to information in a table is buffered in
the SAP buffers, database calls to the database server are not required. Therefore, the ratio of calls/requests gives an overall indication of the
efficiency of table buffering. A good ratio would be 1:10.

Average time per logical DB call

Average response time for all commands sent to the database system (in milliseconds). The time depends on the CPU capacity of the
database server, network, buffering, and on the input/output capabilities of the database server. Access times for buffered tables are many
magnitudes faster and are not considered in the measurement.

Overview of optimal response times in your SAP System

The following times give you an overview of optimal response times in your SAP System. Use the workload monitor to display the current workload
statistics in your system.

Performance Data Time

- Average response time - approx. 1 second (dialog), <1 second (update)

- Average CPU time - approx. 40% of average response time

- Average wait time - <1% of average response time

- Average load time - <10% of average response time

- Average DB request time - approx. 40% of average response time

Database Requests Time

- Direct reads - <10 ms

- Sequential reads - <40 ms

This is custom documentation. For more information, please visit the SAP Help Portal 75
 9/2/2024
- Changes - >25 ms

The times for direct reads and changes should not exceed 10 milliseconds in a healthy database system. The sequen

High Values for Reason

- DB req. (Change/Comm.)

- Database or index problems?

- Load time

- Buffer problems?

- Wait time

- Not enough work processes?

- Locked tasks?

- Long-running transactions?

You can use the workload monitor to...

You can use the workload monitor (Transaction ST03N) to analyze the workload statistics for each task type (for example for background
processing, dialog processing, update processing, ALE, and RFC) for the application servers in your SAP System.

You can use the workload monitor to display and compare the time pro les. A time pro le displays the workload for a speci c task type over
a speci c period of time.

You can display the workload of the instances that are con gured in your SAP System, not just the instance that you have logged on to. You
can also switch easily between the information for these instances.

You can display and analyze the time pro le for one individual task type, or for all task types. You can display the workload for the following
parameters:

- Times

- Database

- Proportion of response time

- GUI times

- All data.

You can use the workload monitor to display the number of users working on an application server. You can display the number of dialog
steps that each user has executed, and check that application server response times are acceptable.

Response Time Overview

This page includes the introduction of interpreting Response Time, Guideline values when analyzing Average response time,and the
troubleshooting guide of key components of response time.

Interpreting the Response Time

The following SAP Notes provide information about how response time is
measured and contains information about the term in general:

This is custom documentation. For more information, please visit the SAP Help Portal 76
 9/2/2024
SAP Note 8963 - De nition of SAP response time/processing
time/CPU time

SAP Note 1063061 - Information about response time in

STAD/ST03

Guideline values when analyzing Average response time/Dialog step are

outlined below.

Wait Time < 10% of total response time (<50ms)

Roll In/Out < 20ms

Roll Wait time < 200ms

Load and Generate < 50ms

Processing time < 2 * CPU Time

Enqueue time <5ms

DB Time < 40% (Response time – Wait time)

GUI time <200ms

Be aware these are only guideline gures, and are NOT a de nitive
indication of a performance issue

You could read more information about the key components of response time from the following pages.

Key Components of Response Time

High Wait time Analysis

Load and Generation Time

Enqueue Time

High Frontend GUI Time

High Processing time

Enqueue Time

Enqueue time is the time during which a work process sets an enqueue request (indicated as Av. Lock Time).Typically, this component of the dialog
response time is rather small, usually less than 5 ms.Following gure is the example of Enqueue time in STAD statistics.

Related SAP Notes and KBAs

97760 - Enqueue: Performance and resource consumption

2252679 - How to analyze an enqueue lock problem.

This is custom documentation. For more information, please visit the SAP Help Portal 77
 9/2/2024
2126913 - ENQU: The enqueue log

2013043 - Performance Problems with Enqueue Work Process

2019532 - Performance of integrated enqueue server

Nearby Technologies

Expert Content Page Enqueue Performance : Analysis

High Frontend GUI Time

Analysis should focus on Front End: Front-End Ping (Network Check), Front-End Hardware, High Volume of Data Transferred, Many Roundtrips. If
you discover that the GUI time is high despite a relatively small volume of data, this can be for two reasons: there may be a hardware bottleneck

on the presentation server or a network bottleneck. Often, the simplest way to analyze this further is to lter out the users who typically
experience these problems from the single-record statistics.

High GUI Time, can sometimes be the result of a non-optimally con gured SAP Easy Access Menu. Check for high GUI Times associated with the
transaction SESSION_MANAGER, if high times are identi ed it is a good idea to run the report ʻEASY_ACCESS_NUMBER_OF_NODES’ via SE38.
This report identi es the number of menu nodes con gured per user. A high number of menu nodes increases GUI time and reduces performance.

When using SAP Easy Access Menu:

Menu should not contain more than 1000 entries (For comparison: The complete SAP menu contains 70,000 entries). The Tree is loaded to the
user context at a glance. A high number of menu entries leads to high memory consumption on the application server and to long response times
for the menu.

The following is the example of High GUI TIME in STAD:

Related SAP Notes and KBAs

2428353 - How to analyze high GUI time on SAP systems

851012 - SAPGUI: Performance trace - technical details

305363 - Create frontend trace le

500235 - Network Diagnosis with NIPING

203617 - ʻHigh memory consumption with Easy Access menu’

357693 - ʻRedundancy avoidance in Easy Access’

This is custom documentation. For more information, please visit the SAP Help Portal 78
 9/2/2024

Nearby Technologies

Expert Content Page Web Dynpro ABAP

High Processing time

Program execution proceeds in the work process.

CPU time and processing time are related. Processing time is an important component of the response time. While processing ABAP coding, CPU
time is needed. Whether the application server can allocate CPU time for the speci c task depends on the overall load on the machine. In short,
processing time does not automatically mean CPU time allocation. If CPU resources are in short supply, processing and response time still grow,
but no real work is done. Ideally, processing and CPU time are about the same size. Processing time is not measured but “calculated” instead. See
below.

Check Operating System Monitor for a CPU Bottleneck as per the below SAP Notes:

994025 - Virtualized OS environments in the operating system monitor

1084019 - OS07N: New operating system monitor

High Wait time Analysis

High Wait time

The dispatcher of the SAP instance receives the incoming request and stores it in the request queue of the appropriate work process type. While
the dispatcher is looking for a free work process, wait time is accumulated. Wait time ends, when the request is being forwarded to a free work
process of the required type. Wait time is the rst component of the overall dialog response time.

Check the number of Dialog work processes in SM50 or TU02 ʻrdisp/wp_no_dia’

Check for long running processes consuming a high number of Work Processes

Check for Work processes in PRIV Mode, this can indicate insufficient extended memory

Is high wait time the Root cause of the poor performance or a symptom of another issue

Activate the /SDF/MON to analyze the running status of work processes

High Time in Business Transaction Analysis(STAD):

High Time in Workload Monitor ST03/ST03N:

This is custom documentation. For more information, please visit the SAP Help Portal 79
 9/2/2024

Related SAP Notes and KBAs

2432675 - High Wait Time analysis in SAP system

2383809 - How to use the SDF/MON tool to analyse performance issues

39412 - How many work processes should be con gured?

2190597 - Work Process Con guration - Best Practices

9942 - Maximum number of work processes

2129291 - Session Priority and Work Process Quota in SAP Kernel 7.4x

Load and Generation Time

All ABAP programs and screens that are required but not yet available in the application server buffers must be loaded or generated. The time it
takes to do this is indicated as load and generation time (Av. Load & Gen. Time). Loading a program also entails accessing database tables that
store the ABAP programs, for example, the tables D010S and D010L.

Load and Generate time is the amount of the time taken by work process to copy and generate or to load and generate ABAP code and screens for
the User request. The load and generator time is high the problem is the buffer sizes is too small (TP program or buffers and CUA buffers).

Check in ST02, verify if the program buffer is sized sufficiently

Up to 10,000 swaps per day is acceptable for the Program Buffer.

HitRatio% and % Freespace should always be considered when analysing Buffer Size

Always ensure sufficient main memory is available before making buffer increases and that all changes are tested before promoting to a
production environment.

Related SAP Notes and KBAs

2504096 - Understanding Program Load (ABAP Load)

1230076 - Generation of ABAP loads: Tips for the analysis

162991 - Generation tools for ABAP programs

185745 - Mass generation due to incorrect load format

379918 - Redesign of the SGEN transaction

2468124 - Too many swaps on program buffer (ST02)

SAP Memory Management

This space introduces the Memory Management System and explains which pro le parameters are available and what are the optimal settings for
your system.

It describes the basic functions of memory management ,buffer,swaps and how best to con gure your system depending on the platform you use,
the available resources, and what you want your system to do.It also describes hardware and operating system requirements and explains how to
monitor your memory management and identify and resolve problems.

For more information, visit Expert Content Page SAP Memory Management System

Features Memory Management Overview

Functions of the SAP Memory Management System - Here you

can nd a description of basic terminology, SAP-speci c memory

This is custom documentation. For more information, please visit the SAP Help Portal 80
 9/2/2024
types and their usage, and implementation of memory
management.

Platform-Speci c Description of Memory Management -

Operating system-speci c details of memory management are
described here: UNIX platforms, Linux, Windows, and IBM i.

Pro le Parameters of Memory Management - You can con gure

memory management using pro le parameters and adjust your
hardware and software requirements.

Monitoring the Memory Management System - Here you can nd

information about monitoring memory management when your
system is running.

Identifying and Correcting Problems - If memory problems occur,

this section helps you to identify and solve these problems.

Related SAP Notes and KBAs

Memory Management:

103747 - Performance: Parameter recommendations as of Release 4.0-

2085980 - New features in memory management as of Kernel Release 7.40

2442188 - Analyzing and Con guring Memory to Increase Performance - Guided Answers

941735 - SAP memory management system for 64-bit Linux systems

117907 - Display of SAP Memory usage in SM04 and ST02

1137734 - Assignment of memory areas, shared memories, and pools

2148571 - Explanation for higher Extended Memory (EM) consumption after upgrade to SAP NetWeaver release 7.4x

2210107 - Default value for parameter rdisp/PG_MAXFS is 250000 8k blocks (2 GB)

2302718 - Changing the memory allocation sequence for NONDIA

2224372 - Remove the limit on maximum segment size on AIX

1382721 - Linux: Interpreting the output of the command 'free'

Buffer & Swaps:

2103827 - Pro le parameters for table buffer as of SAP Kernel Release 7.40

1918603 - ST02 - Swaps in various buffers

2019744 - How to limit overall swap space consumption of the ABAP Server in NW 7.40

1597355 - Swap-space recommendation for Linux

1250278 - Low "Hit Ratio" for "Initial Records" buffer

1267828 - Swaps in program buffer even though plenty of space is free

2468124 - Too many swaps on program buffer (ST02)

Additional Topics

Expert Content Pages:

Analyzing the heap memory usage of an ABAP work process

SAP Help Pages:

Swap Space Requirements

Swap Space Bottleneck During SAP Operation

Slow Response Times for Some Users, Very Good Response Times for Other Users

This is custom documentation. For more information, please visit the SAP Help Portal 81
 9/2/2024
Displaying Buffer and Memory Resources in Transaction ST02

Support Service Related to Performance Analysis

This wiki page introduces the overview of SAP Support Services are closely related to the performance analysis.
All the support services delivered by SAP as per Support Service Portal Page.

Following scenarios can consider using SAP services:

Performance analysis shows general performance issues across the system where there is no speci c pattern or single root cause to the
performance issues identi ed.

The system has recently undergone many changes and no SAP Service has been delivered to verify system performance and con guration
following these changes.

The overall system con guration and parameter settings are requested to be checked It can be a very time-consuming task to verify
system con guration and check all parameters via customer incident.

Be aware that it is important to check whether services have recently been delivered or scheduled, before additional services are implemented
for your systems.

SAP Services that are closely related to performance analysis

SAP EarlyWatch Check

SAP EarlyWatch Alert

SAP GoingLive Check

SAP OS/DB Migration Check

SAP Remote Performance Optimization

For more information about support services related to performance analysis, check Continuous Quality Check & Improvement Services.

Related SAP Notes and KBAs

91488 - SAP Support Services - Central preparatory note KBA

2366584 - The differences of services SAP Early Watch Service, SAP Early Watch Alert and SAP EarlyWatch Health Check

2360708 - How to achieve remote services

551646 - Oracle SQL check rating strategy for EarlyWatch Alert

Table Buffer
Purpose

What is table buffering?

Types

Areas in memory

Parameters

State of a table/key area

Accessing & Bypassing the table buffer

Testing & tracing access to the table buffer

This is custom documentation. For more information, please visit the SAP Help Portal 82
 9/2/2024
Database Interface (DBI) component

SQL statements that refresh the table buffer

Signs which may indicate buffering issues

Runtimes of dialog/background steps are better on certain application servers

Runtimes of dialog/background steps are better after a restart

Database activity in workprocess monitors (SM50/SM66)

SQL activity in ST12 → SQL Summary traces

Buffer refresh & access in performance traces (ST05)

Assessing the health of the table buffer

Overall

Speci c tables <WIP>

KPI Correlations in ST02, ST10, and AL12 <WIP>

Additional/Misc Notes

Purpose

The purpose of this page is to provide a deep understanding of the table buffer(s) and provide techniques for troubleshooting the table buffer(s). It
will help connect concepts of the table buffer to the various monitors and screen at your disposal in any ABAP AS system.

What is table buffering?

SAP Help Page Database Table Buffers

Table Buffering on this page only refers to the table buffers that reside on Netweaver ABAP application servers (and not DB table buffers).

Types
For details on the types of buffering offered, see:
ABAP - Keyword Documentation : Table Buffering - Buffering Types

This is custom documentation. For more information, please visit the SAP Help Portal 83
 9/2/2024

As you can see, a generically buffered table is subdivided based on the values in the rst n key elds to create generic key areas (or simply key
areas for short; this term is important in load times and understanding the buffer state later on).

The more key elds that are included in buffering, the more de ned, and smaller, each generic key area becomes (also depending on the
cardinality/uniqueness of each key eld).

Every fully & generically buffered table is rst divided by client number (MANDT eld). This means that a table which is generically buffered by only
1 key eld is equivalent to full buffering. (For evidence of this, see section explanation of the multiple state.)

To maintain the current buffer settings of a table or to see if a table is even allowed to be buffered as per its developers/owners, use SE13.

Areas in memory
Depending on your kernel release, there may be one or two different table buffer areas in memory. In kernel releases 7.2x and lower there are two
table buffers:

Generic key : tables con gured with Full buffering and Generic buffering are stored here.

Single record : tables con gured with Single record buffering are stored here.

In kernel releases 7.4x and above, there is only one table buffer, where tables of all buffering types are stored.

The basic memory information regarding the table buffer(s) can be checked via transaction ST02.

Depending on your kernel version, the table buffer(s) may or may not be stored in the EG area of EM. SAP Note 2148571 explains this change.

If your system is on SAP_BASIS release 740 with kernel 7.4x or higher, you can observe the proc memory usage of the table buffer per WP ( What is
PROC memory? ).

In SM50 select the WP you are interested in and go to Administration > Work Process > Write Stack. Then click the "View dev traces" button (
Ctrl + Shift + F8). At the bottom, the C-stack and proc memory will be written. In the proc memory section, there should be a DBI_MM tag.
This is the amount of table buffer proc memory currently allocated by this work process.

More information regarding the Write Stack feature can be found in SAP Note 2249313 . These are the same tools used to examine PROC memory
areas for leaks as described in the Memory section of the BC-CST Expert Content Page.

This is custom documentation. For more information, please visit the SAP Help Portal 84
 9/2/2024

Parameters

To control the size of the table buffer(s), refer to the following notes based on your kernel release:

7.2x and lower: SAP Note 480710 - Pro le parameters for table buffers (for SAP Kernel Release 7.2x and below)
7.4x and higher: SAP Note 2103827 - Pro le parameters for table buffer as of SAP Kernel Release 7.40

To in uence buffer synchronization, refer to the parameters in the following:

SAP Help Page Buffer Synchronization

SAP Note 14754 - Pro le parameters for buffer synchronization.

Synchronization is generally not to be changed during normal operation of a NetWeaver system.

State of a table/key area

In ST10 and AL12 (in kernel > 7.4x: AL12 > Monitor > Buffers > Table Buffer > All Objects) you can nd the current state of a table/generic key
area in the buffer.

Valid – Data will be taken from buffer for next read access.

Invalid – The table/generic key area has been invalidated. Data is changed but changes are not committed. Data retrieval would be
from the database.

Pending – Data needs to be refreshed. Any Open SQL that would access this table will instead go directly to the DB.

Loadable – Data will be refreshed on the next execution of an Open SQL statement that would access this table from the buffer.

Loading – The buffer data of this table is currently being refreshed.

Absent – The table is not in buffer at all. For example, no access on the table occurs from the server so far. Data would be loaded
into memory upon next read request.

Multiple – Only visible in ST10 (not AL12). Occurs when the key areas of a buffered table are in different states. E.g. some generic key
areas are pending but some are valid.

Error – Table data cannot be placed into buffer due to error like space, etc.

Displaced - Table was displaced to due insufficient space in the buffer.

State changes in a key area

Note that the terms table & generic key area are generally interchangeable in this section.

Absent > When a server rst starts up all key areas of tables that are to be buffered start in an absent state. The rst access to these key areas will
Loading1 > cause them to load/refresh.
Valid

Valid > When the contents of a table are changed, the relevant generic key area of that table in the table buffer is invalidated and goes into a pending
Invalid2 > state.
Pending

Pending > A key area stays in pending status until a number of Open SQL requests (typically 5) have attempted to retrieve data for this table from the
Loadable buffer (but been unable to due to its current state of pending).
After this, it will go into the loadable state.

Loadable > A key area that is loadable will be loaded/refreshed on the next Open SQL request that requires data from that key area. The loading is done
Loading1 > synchronously.
Valid

Valid > When there is insufficient space in the table buffer to load/refresh a table, a less used table is displaced.
Displaced This typically occurs when the table buffer is undersized, you are trying to buffer very large tables and the buffer sizing isn't adequate, or if a
memory leak is consuming usable space as in SAP Note 2404710 - Table buffer: Memory leak in shared memory.

Displaced > ? Unsure if this is like the absent > valid scenario or the pending > valid scenario
> Valid

1. Loading should be quick and difficult to spot in ST10/AL12. If Loading is frequent or long running, perhaps the size of the table/generic key
areas & invalidation rate are not suitable for the current buffer settings.

2. As mentioned in the last section: I've never observed status Invalid in ST10/AL12. The state is generally seen to go from Valid to Pending.

This is custom documentation. For more information, please visit the SAP Help Portal 85
 9/2/2024
Additional information on the buffer state can be found here:
How is buffer state and table call statistics changed?

Explanation of the Multiple state

In ST10, tables that are fully buffered or generic key buffered can display state Multiple. This is because different generic key areas can be in
different states at the same time and ST10 simply aggregates the data for all generic key areas into a single entry, thus, if multiple generic key
areas have different states, multiple is displayed in ST10.

If you want to see the individual statistics for the generic key areas of a table, you have to use AL12 > Monitor > Buffers > Table Buffer > All
Objects.

Because fully and generically buffered tables are rst divided by client number, even a fully buffered table can have a state of multiple in a system
with multiple clients.

+ For example...

Accessing & Bypassing the table buffer

Only certain Open SQL statements will access the table buffer. For details of what statements can and cannot access the table buffer, see the
ABAP - Keyword Documentation pages for:

Table Buffering - Buffering Types

&
Table Buffering - Restrictions

Testing & tracing access to the table buffer

To test access to the table buffer, use SE17.

SE17 is similar to SE16, however, SE16 always add a TOP N clause (or equivalent, depending on the database) to the native SQL statement,
bypassing the buffer.

It is possible to directly trace buffer requests in ST05 using the Buffer Trace trace type. This is useful if you are unsure whether or not an ABAP
statement uses the table buffer.

+ Example...

Database Interface (DBI) component

The DBI is responsible for managing & maintaining the table buffer (recall that the area in PROC memory where buffered tables are stored is
named DBI_MM).

Once an Open SQL statement is encountered in an ABAP program, the rst component to receive the Open SQL request is the DBI. The DBI then
determines if it can ful ll the request based on the type of statement (see the Statements that access/bypass the table buffer section) and the
state of the requested table in the buffer and handles the request accordingly or sends it to the DBSL.

Here is a rough overview of what happens when an Open SQL statement is encountered in an ABAP program (also, see the rst diagram at the top
of this page).

<to do: make this a graphic/ ow chart>

1. An Open SQL statement is encountered and the request is sent to the DBI

2. The DBI determines if it can ful ll the request using the table buffer based on statement type

1. Able:

1. For the table in the request, the DBI then checks the state of said table in the table buffer

This is custom documentation. For more information, please visit the SAP Help Portal 86
 9/2/2024
1. Valid:

1. The request is ful lled by the DBI using the buffered data

2. Loadable:

1. The DBI refreshes the data in the buffer by querying the database directly (via the DBSL; the state of the table
will be Loading here; see next section for more information)

2. The table goes into the Valid state (assuming no errors occur during table loading)

3. The request is then ful lled by the DBI using the newly buffered data

3. Anything else:

1. The request is forwarded to the DBSL

2. Depending on the state of the table, it may go from Displaced to Pending, or Pending to Loadable.

2. Not able:

1. The request is forwarded to the DBSL where it is transformed into a native SQL statement the database will understand.

SQL statements that refresh the table buffer

When key areas of a table in the table buffer are refreshed, there is a recognizable pattern of SQL calls made to the DB to obtain the data needed
to re ll that key area.

It is good to be able to recognize these statements as we regularly encounter issues of:

sudden increase in DB response time

WP spending a lot of time on action sequential read (on a supposedly buffered table)

high CPU consumption in the DB

Which are caused by inadequate buffer con guration.

In newer kernel releases, the DBI/DBSL will add the SQL comment "/* Buffer Loading */" to the statement that is refreshing that generic key
area. In this case it is very easy to identify these statements and the rest of this section is negligible.

If n is the number of key elds by which to buffer a table (fully buffered table: n = 1 (only MANDT) ; generic buffered table: n >= 1), then, Generic key
areas in the buffer:

Contain all elds/columns of the table -> SELECT * is used to retrieve all records from the table.

Are sorted by primary key -> the SQL statements uses an ORDER BY clause.

Are identi ed by the rst n key elds (including MANDT) -> the where clause will contain n predicates (MANDT + n - 1 other key
elds)

The actual statement will vary depending on the type of table (transparent, pool, etc).

+ For example...

Signs which may indicate buffering issues

There are several different signs/symptoms that may indicate an inadequitely con gured table buffer or poorly con gured buffer settings for
particular tables.

In case the problems below are noticed in your system, the troubleshooting steps are generally the same; see Assessing the health of the table
buffer.

Runtimes of dialog/background steps are better on certain application servers

If you nd runtimes are more favorable on certain application servers, and worse on others, it is worthwhile to check the table buffer con guration
on those servers. The relevant pro le parameters may be con gured differently on other application servers and may not be sized adequately on

This is custom documentation. For more information, please visit the SAP Help Portal 87
 9/2/2024
those servers.

To determine if a table buffer is healthy on a particular server, see Assessing the health of the table buffer.

Runtimes of dialog/background steps are better after a restart

If you nd runtimes are more favorable after restarting the application server, there may be a memory leak in the table buffer. To con rm this, see
the Assessing the health of the table buffer section.

The most common table buffer leaks that we encounter are detailed in SAP notes 2404710 & 2466145.

Database activity in workprocess monitors (SM50/SM66)

There may be a buffering problem if:

when observing the workprocess monitor you observe work processes often and repeatedly waiting on Sequential Read and the
table listed in the action detail column is a table for which buffering is con gured in SE13

And, in the ST04 session monitor (database dependent) you nd that the SQL statements being executed are statements that:

should be accessing the buffer: Accessing & Bypassing the table buffer

or are refreshing the buffer: SQL statements that refresh the buffer

<to do: add example>

SQL activity in ST12 → SQL Summary traces

There may be buffering problems if, when you've collected an ST12 trace of the performance problem, you notice long runtimes of SQL requests on
tables that are supposed to be buffered.

+ Example...

Buffer refresh & access in performance traces (ST05)

There may be buffering problems if, when a performance trace of the performance problem is collected, you notice many long running statements
that match the pattern of a buffer refresh/load request ( SQL statements that refresh the buffer ), each followed by another request to the same
table under a different cursor/SQL statement which should be accessing the buffer ( Accessing & Bypassing the table buffer ). This indicates the
buffer refresh attempt did not complete successfully and the original request had to be forwarded to the DB to be ful lled.

+ Example 1...

+ Example 2...

Assessing the health of the table buffer

Evaluating the health of the table buffer requires a certain level of judgement and common sense. It's possible the values present in monitors such
as ST02 are not conclusive; they may display questionable values, but the table buffer may not actually be the root cause of a performance issue.

Therefore, in this section, anytime guidelines are mentioned on what values they should be (or be above/below), you should consider whether or
not you're actually seeing Signs which may indicate buffering issues in your system. If your performance issues are not actually related to
buffering, it may not be worthwhile to focus efforts on the table buffer.

Additionally, the values recommended are intended for production systems; measurements are much more liberal for test and development
systems.

This is custom documentation. For more information, please visit the SAP Help Portal 88
 9/2/2024

Overall
The process of evaluating the health of the table buffer overall roughly equates to the following:

Check the KPIs in ST02

The rst step in overall analysis is to check ST02 and see if the table buffer suffers from a low hit ratio or frequent swapping.

1. The hit ratio should be as close to 100% as possible.

2. The % Free Space should be >10

3. The % Free directories should be >10

4. The number of Swaps should be near zero

These values must also be kept in perspective of the startup time. For example:

The hit ratio can be lower than normal if the system has started only within the last several business days.

The number of swaps may be in the thousands, but if the system has been running for more than a month, it may be
acceptable.

The amount of free space and the number of free directories are below 10% very shortly after system startup then
concern should be raised

To better understand how the table buffer behaves over time, and to identify days where high swapping occurred, use the History view
(Shift+F6 ) . (Note that depending on your basis release, the swap statistics in the History view may or may not be cumulative; use
common sense when determining if the swap statistics are for one particular day, or aggregated for all previous days.)

In a distributed system, each application needs to be checked individually. You can check other application servers using SM51 followed by
transaction ST02, or by using the Server names buttons in the History view to cycle through each application server.

If any questionable KPIs are noticed in ST02, it may indicate the following:

An undersized table buffer

An overabundance of buffered tables (by table size)

A memory leak (e.g. SAP notes 2404710 & 2466145)

More information is needed to determine the true reason behind said KPIs.

ST02 cannot tell you if:

The buffering performance issue is related to invalidation rates in speci c tables (ST10 is required for this)

Check the KPIs in AL12

If you nd the table buffer is low on space, suffering from frequent swapping or suffering from a low hit ratio; ensure the space being used by
the table buffer is valid, and not wasted. Do this using AL12 > Monitor > Buffers > Table Buffer > Overview.

This is custom documentation. For more information, please visit the SAP Help Portal 89
 9/2/2024

1. Space with Valid Objects should be within 30% of Used Space, if you notice the space with valid objects is very small compared to the used
space, a memory leak may be indicated as per SAP Note 2466145.

2. The number of Valid Objects should be as close to the number of Total objects as possible. If the number of Loadable objects is signi cant
compared to Total Objects, it may indicate an undersized table buffer, or an overabundance of buffered tables.

If you don't notice any issues with the ratio of Valid to Used Space, then it means the space consumed inside the table buffer is legitimate
and not due to a memory leak. This means the swapping is due to:

An undersized table buffer

Or an overabundance of buffered tables

Examples

+ Example 1 - Healthy...

+ Example 2 - Questionable...

+ Example 3 - Memory Leak...

Speci c tables <WIP>

Even if you have isolated the performance issue to a single business process, transaction, or table, I recommend checking the Overall health of the
table buffer rst. As any tuning or changes made to single tables will be for naught it the root cause is actually an overall unhealthy table buffer.
Once you've con rmed the table buffer is healthy overall, then continue with examining the speci c table(s).

To be used in this section:

2404710 - Table buffer: Memory leak in shared memory

KPI Correlations in ST02, ST10, and AL12 <WIP>

ST02 -> Detail Analysis Menu -> Generic Key/Single Record → "AL12 -> monitor -> buffers -> table buffer- > overview "

1. Size Allocated → Buffer Size / 1024

2. Size Available → Data Space / 1024

3. Size Used → Space with Valid Objects / 1024

4. Size Available - Size Free → Used Space / 1024

This is custom documentation. For more information, please visit the SAP Help Portal 90
 9/2/2024
ST12 -> Detail Analysis Menu -> Generic Key/Single Record → "AL12 -> monitor -> buffers -> table buffer -> shared memory"

1. Size Free → "Space Usage in KB" of <free>

"AL12 -> monitor -> table buffer -> overview"

1. Efficiency → Used Space / "Space with Valid Objects" (gone in 740+)

2. "Free Directories" → "Directory Size" - "Total Objects"

<WIP>

"AL12 -> monitor -> table buffer -> shared memory"

A detailed breakdown of the shared memory area of the table buffer.

First view provides the number of blocks and their total size broken down by block/area type.

If SAP Notes 2243084 and 2248618 are applied then Double clicking on any one of those areas provides a histogram-like breakdown of the
data blocks in shared memory area.

Of particular interest is the <free> block type. Note 2253735 explains this type of block and buffer fragmentation. 16KB block initially
reserved, if the table does not ll this, it is shrunk, which may leave gaps. Thus, a large amount of dictionary entries without a sufficient
buffer size may exasperate buffer fragmentation.

ST10 & AL12

In ST10, sum of "Buffer size" column of all valid tables is close to (slightly higher, but not exactly equal to) the "Space with Valid Objects" metric in
AL12 -> "monitor -> buffers -> table buffer -> overview"

The stats given in "AL12 -> monitor -> buffers -> table buffer -> all generic tables/all single-buffered tables" appear to match the stats of ST10,
however, AL12 is more granular, listing each area of generic buffering rather than aggregating by table name (i.e. there is no such thing as a
"multiple" state in "AL12 -> monitor -> buffers -> table buffer -> all generic tables/all single-buffered tables")

Additional/Misc Notes
SAP Note 1099937 - Improved diagnosis options for buffer synchronization.

SAP Note 2253735 - Fragmentation in the table buffer (Includes enhancements to the AL12 > "Monitor -> Buffers -> Table Buffer -> Shared
Memory" screen).

SAP Note 23877 - Performance: Buffering condition tables.

SAP Note 1011158 - Table buffering on a SAP instance

SAP Note 2404710 - Table buffer: Memory leak in shared memory

Web-Based Interfaces

This page is used for the HTTP analysis, Web based application area, Fiori, CRM Web GUI,EP Portal Performance analysis. etc.

Httpwatch

HttpWatch is a third-party browser plugin which can be used to trace the HTTP/HTTPS traffic between the browser and server triggered by each
action you take within a web application. It can be downloaded via http://www.httpwatch.com/download/.
This tool can be used to capture trace le for scenarios that have a performance issue and get *.hwl les for further analysis.

How to use HttpWatch

Using HttpWatch

HTTP Watch - HTTP Gallery

Tips and Tricks

This is custom documentation. For more information, please visit the SAP Help Portal 91
 9/2/2024
How to Save HttpWatch Trace automatically

1697063 - HttpWatch - Performance Analysis

1558903 - How To Trace a Portal Scenario Using HttpWatch

1817693 - How to trace the ITS Service "WEBGUI" directly using HttpWatch

Fiori Performance

Browser caching on Fiori

Nearby Technologies

CRM Web Client UI Framework

Web Dynpro ABAP WIKI Performance issues

Related SAP Notes and KBAs

2255214 - Analyze CRM UI performance issues on backend using STAD

1817724 - How to create HttpWatch trace to troubleshoot BSP related problems

2424394 - Using HTTP trace and ABAP trace to diagnose slow response on customer portal

Caching in Fiori Application

Browser caching is an important part of Fiori Launchpad performance, as it's explained in the following SAP Notes:

2447857 - Fiori Launchpad: How to check browser settings for better performance

2421371 - Understanding Launchpad performance Issues

There are two types of resource available in the Fiori Application .

Static

There are "static" resources like MIME, js, css, that need to be fetched once (on the rst launch), after which they are untouched for the duration
of the caching .

Dynamic

This is the data that is retrieved via odata services. The odata service are call each time data is request from the backend , this is not cached to
ensure that the data is current.

If an application is loading slowly even when caching is on this maybe due to issue getting data from the backend via odata service.

This can be con rmed by running a HTTPWatch trace and ltering by the longest time . If most time is spent on static object caching may need to
be activated. If the issue is with ODATA service this needs to be checked further.

Whenever you experience slowness, it should be investigated in debug tools of your browser, which resources are slow to load.

With proper caching the static resources should not burn too much time.

This is custom documentation. For more information, please visit the SAP Help Portal 92
 9/2/2024

This is custom documentation. For more information, please visit the SAP Help Portal 93