SAP Architecture 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.
SAP performance is won or lost in four places: the database, with expensive SQL and missing indexes; application-server buffers; the mix of dialog and background work processes; and custom ABAP with SELECTs in loops. ST03, ST04, SM50, SM66, ST22 and ST05 show where time actually goes. Baseline, find the bottleneck, change one thing, measure again.
- 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.