Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 4 of 6

Reading SAP performance evidence

9 min

Listen to this lesson

0:00 / 6:39

Load tools tell you that something is slow. SAP's own statistics and traces tell you why. A test lead does not need to tune SQL, but must know which evidence exists, ask Basis and developers for it, and read it well enough to separate "the system is overloaded" from "one report is badly written."

Workload statistics: where the time goes

The workload monitor (ST03) breaks response time into parts. In SAP's documentation, response time is wait time plus execution time. Wait time is time spent queuing for a free work process; high values suggest overload. Execution time includes loading and generating programs, roll-in and roll-out, ABAP processing, database time, enqueue (lock) time and RFC time. CPU time is measured separately and is not added into response time. Time on the network and in the front end is not included, so a user on a slow connection can feel delays the statistics don't show.

Reading the response time split in ST03 tells you who should investigate next, before anyone starts tuning.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-306
Wait timeQueuing for a work process: overload or too few work processes
Load and generationPrograms and screens loaded: buffers or recent transports
Database timeSQL: expensive statements, missing selectivity, large volumes
ABAP processingProgram logic: loops, internal tables, custom code
Enqueue and RFC timeLocks and remote calls: contention or slow partners
Components of dialog response time in the workload statistics, and what a high value usually points to.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-306

Traces: one process in detail

When one transaction is slow, the performance trace (ST05) records what it did. It can trace SQL statements, enqueue (lock) calls, table buffer access, RFC calls and HTTP communication. The usual pattern: activate the SQL trace for the test user, run the slow step once, deactivate, then display the trace and sort by duration or look for repeated identical statements. From an entry you can display the execution plan. Developers also use ABAP profiling to see whether time is spent in ABAP logic or in the database. Short dumps (ST22) and the system log (SM21) show errors that a load test may have triggered.

A performance trace isolates one slow step, and the statement it finds becomes a precise task for the developer.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-306

SAP HANA evidence

On the database side, SAP HANA monitoring shows statements currently running long and blocking situations, and lists the most critical statements by runtime. The expensive statements trace records SQL statements whose runtime exceeds a configured threshold; it is deactivated by default, so ask Basis to switch it on, with an agreed threshold, before the load test. The SQL plan cache keeps statistics per cached statement, such as execution count and total and average runtime, which is a quick way to find a statement that is individually fast but executed millions of times.

Symptom in the load testEvidence to ask forUsual owner
Everything slows down together at peakWorkload statistics: wait time, CPU and memoryBasis (Sam)
One transaction slow, others finePerformance trace of that step; ABAP profileDeveloper (Kenji's team) or functional owner
Database time dominatesExpensive statements trace, SQL plan cacheBasis with developers
Errors under loadShort dumps, system log, lock entriesBasis and developers
Slow only for remote usersNetwork and front-end measurementsInfrastructure team

Matching symptoms to SAP evidence and to the people who can read it.

  1. Agree before the testWhich statistics and traces Basis will collect, thresholds, time windows
  2. RunLoad test with synchronized clocks and labeled test phases
  3. CorrelateTool response times next to SAP workload and database statistics
  4. Drill downTrace the worst processes; find the expensive statements
  5. Fix and rerunTuning action, then the same test again for comparison
A joint test-and-Basis analysis loop. Agree the evidence before the run, not after.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-306

What would you do?

During Contoso's month-end load test, response times for every process rise sharply at the same moment. Workload statistics show high wait time; database time is normal. What is the most likely conclusion?

Key points
  • Workload statistics split response time into wait, load, database, ABAP, lock and RFC time; CPU time is separate.
  • The performance trace shows what one slow step did; developers use ABAP profiling alongside it.
  • SAP HANA's expensive statements trace (off by default) and SQL plan cache find costly SQL.
  • Agree evidence collection with Basis before the test and correlate tool results with SAP statistics.

Check your understanding · not graded

Lesson check

  1. 1. What does high wait time in the workload statistics usually indicate?

  2. 2. Which SAP HANA trace is off by default and records SQL over a runtime threshold?

  3. 3. Is CPU time added into the dialog response time?

  4. 4. Which tool records the SQL, lock and RFC calls of one slow transaction?