Performance
SAP performance depends on how well the three tiers, and especially the database and application-server buffers, are sized and tuned. Good performance is designed and monitored, not hoped for, and it is a core Basis discipline.
Baseline with the monitors, find the real bottleneck, change one thing, re-measure.
- SAP provides rich monitoring, ST03 (workload analysis), ST04 (database), SM50/SM66 (work processes), ST22 (dumps) and SQL trace…
- On HANA, in-memory column storage removes many traditional bottlenecks and lets analytics run on live data.
- Database: the usual bottleneck, indexing, expensive SQL, and (pre-HANA) missing aggregates.
- Watch out: Tuning by guesswork instead of measurement.
Where performance is won or lost
- Database: the usual bottleneck, indexing, expensive SQL, and (pre-HANA) missing aggregates.
- Application-server buffers: caching programs and data to avoid database hits.
- Work-process configuration: the right mix of dialog vs background processes.
- Custom ABAP: inefficient code (SELECTs in loops) is a top cause of slowness.
Monitoring tools
SAP provides rich monitoring, ST03 (workload analysis), ST04 (database), SM50/SM66 (work processes), ST22 (dumps) and SQL trace (ST05). These let you see where time is actually spent rather than guessing, the golden rule of tuning.
HANA changes the picture
On HANA, in-memory column storage removes many traditional bottlenecks and lets analytics run on live data. But it also rewards pushing logic down to the database (code-to-data) and punishes old habits like row-by-row processing.
A tuning method
Baseline with the monitors, find the real bottleneck, change one thing, re-measure. Most dramatic gains come from fixing bad custom SQL and right-sizing the database and buffers.
Common pitfalls
- Tuning by guesswork instead of measurement.
- SELECTs inside loops in custom ABAP.
- Under-sized buffers or database.