ABAP Performance Tuning 1
As a developer we have to give thought to performance of the program we are developing, because every object or report that we develop is to be tested in real time where the response time is all that matters.
Imagine if a truck is waiting with goods for a document and that document printing program is taking more than 5 minutes which would be a performance bottle neck.
This will be a series of blogs focusing on the Performance issues in ABAP, how to analyze them, rectify and give the perfect solutions in case of performance problems.
The first thing when it comes to performance issues is to find out where the problem exists. So we need to analyze individual objects in the process flow and find what the root cause of the problem is.
While doing analysis of anything you should ask yourself some W questions which are?
What to analyze?
- An object requiring analysis can be a report, a transaction, or a series of reports or transactions, which form a business process or part of a business process.
Where to analyze?
- The SAP architecture is divided in three landscapes Development, Quality and Production. To analyze an object beforehand we need to do our analysis in Quality system rather than reactively when a problem occurs in Production.
Who should analyze?
- If you are an ABAP programmer you should make sure that what you are delivering is tested proactively and there are no performance hinges in your code.
- A performance analyst is another person who is responsible for the analysis. He is the better person to analyze the object considering various scenarios because he has the knowledge of ABAP and R/3 architecture. So he will be able to pin point the problem cause.
And main thing is you should have prerequisites for analysis ready with you, what could these be?
- The objects having performance problem are known to you.
- There should not be problems with Basis or database or hardware.
- You should have somebody who is aware of the business process.
- And finally we need data samples.
As you know the R/3 System has a three-layer client/server architecture, with a presentation layer, an application layer and a database layer. The presentation layer and the application layer are scalable. This means that if there is a hardware bottleneck, you can extend the system by adding more frontends and application servers. The database layer, as the central data repository, is not scalable.
ABAP performance analysis has two main areas of focus. One goal is to reduce the run time of programs on the application server, thereby reducing the CPU load. Another goal is to reduce the database load. Reducing the database load is particularly important since the database software is not scalable.
If you are focused to find the exact cause for performance hampering then we need to analyze each transactional step performed during a dialog processing.
A transactional step corresponds to a change of screens. During an update or spool process, each request counts as a transactions step. Background processing can consist of one or more transaction steps.
The transaction step parts are numbered above as follows:
1) Sending the user request to the application server.
2) Placing the user request in the dispatcher queue if all R/3 work processes are occupied.
3) Assigning the user request to an R/3 work process.
4) Rolling the user context in to the R/3 work process.
5) Attempting to satisfy the SQL statement from the R/3 buffers.
6) Sending the SQL statement to the database server.
7) Attempting to satisfy the SQL statement from the database buffer.
8) Importing from the database the data blocks missing in the database buffer.
9) Displacing data blocks from the database buffer.
10) Sending the results of SQL statements to the application server.
11) Changing buffered table content following database table changes.
12) Rolling the user context out of the R/3 work process.
13) Sending the results of the user request to the presentation server.
|Aggregated Statistics Record-Global|
To display the statistics for each transaction step (single statistics records), use Transaction ST03G, or from the R/3 initial screen, choose Tools >> Administration >>Monitor>> Performance>> Workload>> Aggregated Statistics Record-Global.
In the Analysis view you can check for all the areas where the workload is high and low. The Workload overview gives you overview of ALEs, Background Jobs, Dialog programs, HTTP access, RFC calls and SPOOL requests etc.
In the next blog we will see SQL performance trace. So keep looking for new things.