SAP Performance Optimisation
Slow SAP isn't just a user experience problem — it compounds at scale. Slow reports delay decisions. Slow batch jobs push overnight runs into business hours. Slow Fiori apps reduce adoption. Slow interfaces accumulate backlogs. 2iSolutions' SAP performance optimisation practice diagnoses the root causes — whether ABAP code, database configuration, HANA memory, Basis parameters or integration design — and fixes them at source, not with workarounds.
From symptom to root cause — what slow SAP actually means
Users report "SAP is slow." That's a symptom, not a diagnosis. The same user complaint can have six different root causes — and the fix for each is completely different. Treating the symptom (adding hardware, restarting services) without identifying the root cause means the problem returns.
Reports take 20+ minutes to run — users print to PDF and email instead of running live
Missing database indexes on selection fields; ABAP SELECT fetching full table then filtering in application layer
Overnight batch jobs running into business hours — users cannot post transactions in the morning
Batch programmes running single-threaded without parallel processing; wrong runtime sequence causing locks
Fiori apps take 8–12 seconds to load — users switch back to SAP GUI transactions
OData service returning full dataset without server-side filtering; no paging implemented; cold-cache on Fiori launchpad
Month-end closing takes 3 days — finance team working weekends to complete
Financial closing jobs not parallelised by company code; custom validations running redundant database reads per document
SAP interface to logistics system running hours behind — delivery updates arrive after trucks have left
IDOc processing bottleneck — inbound port running single thread; error IDOcs blocking the queue
After S/4HANA upgrade, key transaction significantly slower than before
HANA query plan changed post-upgrade; index not carried over; custom code using deprecated API now executing differently
Six performance optimisation service areas
SAP HANA Performance
HANA memory configuration, column store optimisation, table partitioning, plan cache analysis and HANA-specific SQL query tuning. Post-migration performance benchmarking and heap memory profiling. Lava International achieved 2–3× performance improvement from our post-HANA migration tuning engagement.
ABAP Code Optimisation
Identifying and rewriting slow ABAP — replacing full-table SELECT with indexed range reads, eliminating nested SELECT inside loops, converting ABAP sorting to database ORDER BY, implementing parallel processing with CALL FUNCTION IN BACKGROUND TASK and reducing redundant function module calls in custom programmes.
SAP Basis & System Parameters
Work process configuration (dialog, background, update, spool), memory profile tuning (PHYS_MEMSIZE, em/initial_size_MB, ztta/roll_extension), buffer configuration (program buffer, CUA buffer, table buffer) and SAP kernel parameter optimisation — the infrastructure layer most often neglected between upgrades.
Batch Job & Background Processing
Batch schedule analysis, parallel processing implementation for MRP, billing runs and financial period close, RDBMS lock analysis to eliminate batch serialisation, job class prioritisation and background work process configuration. Month-end close programmes that run overnight instead of across weekends.
SAP Fiori & OData Performance
OData service response time analysis, server-side filtering and paging implementation, SAPUI5 model binding optimisation, Fiori Launchpad cache configuration, ICM parameter tuning and CDS view performance for Fiori Elements apps. Fiori performance often degrades post-go-live as data volumes grow — we address it before users abandon the apps.
Interface & IDOc Performance
ALE/IDOc throughput analysis, inbound and outbound port configuration, IDOc error queue management, parallel tRFC processing, ABAP proxy and SAP Integration Suite iFlow performance. Interface backlogs in logistics, finance and HR are frequently the hidden performance bottleneck in integrated SAP landscapes.
The tools we use to diagnose and verify SAP performance
Performance problems cannot be fixed by guessing. Each tool below targets a specific diagnostic layer — from end-user response time to database execution plans. The right diagnosis determines the right fix.
Work Process Monitor
Live view of all SAP work processes — identifying blocking, long-running dialog steps and background jobs consuming excessive CPU or runtime.
SQL Trace
Traces every database call from an ABAP transaction — identifying full-table scans, missing indexes, excessive round trips and expensive JOIN operations.
ABAP Runtime Analysis
Profiles ABAP programme execution — identifying which statements consume the most runtime, where loops are expensive and where SELECT statements should be redesigned.
ABAP Trace
Combined ABAP and SQL trace for specific transactions — providing a complete execution profile showing both application and database performance together.
HANA Performance Analysis
SAP HANA's native monitoring — memory consumption, column store delta merges, plan cache hit rates, expensive SQL statements and HANA service health.
Buffer Analysis
SAP buffer statistics — identifying buffer overflow causing disk reads, undersized program buffers and table buffer hit rates that should be >98%.
Workload Statistics & Log
Historical workload data showing response time trends, peak usage periods, database request times and roll-in/roll-out waiting times across all transactions.
SAP Early Watch Report
SAP's automated system health report — surfacing configuration gaps, missing corrections, performance deviations and workload hotspots that require attention.
Five-phase performance optimisation methodology
Performance optimisation is not a one-time activity — degradation recurs as data volumes grow, user counts increase and new customisations are added. Our methodology is designed to deliver measurable improvement and then sustain it.
Baseline
Measure current response times, batch runtimes, buffer hit rates and HANA memory — documented before any change
Diagnose
ST05, SE30, SM50, HANA Cockpit and Early Watch Analysis to identify root causes — not symptoms
Prioritise
Issues ranked by business impact and fix complexity — highest ROI optimisations delivered first, not easiest
Optimise
ABAP rewrite, index creation, parameter tuning, parallel processing, batch restructuring — tested in QA before production
Validate & Monitor
Before/after measurement, regression check, monitoring alerts configured — improvement documented, not claimed
What we measure before and after
- Dialog step response time (target: <1 second)
- Database request time per transaction
- Batch job end-to-end runtime
- Buffer hit rates (target: >98%)
- HANA memory peak and average
- OData service response time
- IDOc throughput (documents/hour)
What improvement looks like in practice
- Reports running in seconds, not minutes
- Batch jobs completing before business hours
- Fiori apps loading under 2 seconds
- Month-end close in 1 day, not 3
- Interfaces processing in real-time, not batched
- Users staying in Fiori — not reverting to GUI
- HANA memory within configured parameters
Performance transformation in practice — Lava International
What makes our performance optimisation practice effective
Root Cause — Not Hardware
Adding CPU and RAM delays the problem; it doesn't fix it. An ABAP programme doing a full-table scan gets slower as data grows, regardless of how powerful the server is. We fix the ABAP, add the index, restructure the batch job — so the improvement scales with the fix, not with the hardware budget.
Before & After Measurement
Every optimisation engagement starts with documented baselines — transaction response times, batch runtimes, buffer hit rates, HANA memory profiles. After changes, we measure the same metrics and present the comparison. Improvement is documented, not claimed. Clients know exactly what changed and by how much.
HANA-Native Tuning Experience
SAP HANA requires a different performance approach than traditional RDBMS — column store behaviour, delta merge cycles, result cache configuration and HANA-specific SQL optimisation. Our team has executed HANA migrations and tuning engagements — including Lava International's 2–3× performance improvement — with hands-on HANA Cockpit depth.
Full Stack Coverage
Performance problems rarely have a single root cause in one layer. A slow Fiori report might be ABAP, OData, network, HANA or all four. We cover all layers — ABAP, HANA, Basis, Fiori/OData, interface and batch — so the diagnostic doesn't stop at the layer boundary of a specialist who only knows one area.
Safe Change Process
Performance changes — index creation, ABAP rewrites, parameter modifications — can introduce regressions if not managed carefully. We develop and test every change in a QA environment equivalent to production before applying to live. ABAP changes go through transport management; parameter changes are staged and rolled back immediately if metrics worsen.
Sustained Under AMS
Performance degrades as data grows, new customisations are added and user volumes increase. Our AMS clients benefit from performance monitoring as an ongoing deliverable — flagging degradation trends before they surface as user complaints, and tuning proactively rather than reactively.
SAP performance optimisation from a Gold Partner with 21 years of technical SAP delivery
Our performance practice spans HANA tuning, ABAP optimisation, Basis configuration and batch restructuring — across S/4HANA, ECC and Business One landscapes in manufacturing, high tech, pharma and FMCG.
SAP performance optimisation: frequently asked questions
How do you identify what's causing slow SAP performance?
We use SAP's native diagnostics — SM50/SM66 for live work process analysis, ST05 for SQL tracing (identifying full-table scans and missing indexes), SE30/SAT for ABAP runtime profiling, ST02 for buffer analysis and the SAP Early Watch Alert for systemic issues. For HANA systems, the HANA Cockpit provides memory, plan cache and expensive statement analysis. Every engagement starts with a diagnostic phase before any changes are made — guessing at optimisations without diagnosis wastes time and can introduce regressions.
What is the most common cause of slow SAP reports?
Missing or poorly chosen database indexes are the most frequent root cause. A report running a SELECT on VBAK (sales order header) without an index on the date field will scan the entire table — getting progressively slower as the table grows. The second most common cause is ABAP code that retrieves a large dataset and then filters it in the application layer, rather than filtering at the database level via the WHERE clause. Both are diagnosable with ST05 in under an hour; fixing them typically reduces runtime from minutes to seconds.
Can SAP performance be improved without hardware upgrades?
In most cases, yes. Hardware upgrades address capacity constraints — they don't fix architectural problems. An ABAP programme with a full-table scan in a loop is slow regardless of how fast the server is; fixing the SQL eliminates the problem. Buffer undersizing, missing indexes, non-parallelised batch jobs and inefficient OData services are all software and configuration issues. Hardware helps when the root cause is genuinely capacity — peak user load exceeding work process limits, for example — but that's diagnosed separately from code and configuration issues.
How does SAP HANA improve performance compared to a traditional database?
HANA stores data in a column-oriented format in memory — meaning aggregation queries (SUM, COUNT, GROUP BY) read only the relevant column without scanning full rows, and compressed in-memory data reduces read volume significantly. Analytical queries that took minutes on row-store databases often run in seconds on HANA. However, HANA requires configuration — memory sizing, column store delta merge parameters, result cache configuration and query plan optimisation — to realise its performance potential. A poorly configured HANA system can underperform a well-tuned traditional database.
What causes SAP batch jobs to run longer after an upgrade?
Upgrades change the ABAP runtime environment, database execution plan generation and, in HANA, the in-memory data layout. A batch job that ran in 2 hours on ECC may run in 4 hours after S/4HANA conversion if the ABAP uses APIs that behave differently on S/4HANA, if HANA's query planner chooses a different execution strategy, or if the S/4HANA data model changes how the programme accesses data. We benchmark batch runtimes in the upgraded test system against production baselines before go-live — and address regressions before they reach production.
How long does a SAP performance optimisation engagement take?
A focused performance assessment — covering the top 10 worst-performing transactions and batch jobs — typically takes 2–3 weeks: one week for diagnostic analysis, one week for root cause identification and prioritisation, and delivery of a remediation plan. Implementation of the top-priority fixes typically takes an additional 2–4 weeks depending on ABAP complexity and the number of indexes and parameter changes involved. Some fixes (adding a database index, adjusting buffer parameters) deliver improvement immediately; others (ABAP rewrites) require development, testing and transport cycles.
SAP running slower than it should — or slower than it used to?
A performance diagnostic engagement starts with a structured assessment — ST05, SE30, Early Watch analysis and HANA Cockpit review — to identify the top causes and the highest-ROI fixes before any changes are made. No guessing, no hardware recommendations before root causes are established.