In the Application Performance Engineering, all phases are equally crucial right from identifying the performance test scenario to the Analysis & tuning. Performance improvement is normally an iterative process until the product reaches a stable performance state abiding by all the performance standards.
1. Identifying what to test
In this phase, if we do not identify the precise performance test scenarios the complete cycle will focus on inappropriate areas for performance tuning. In this step we need to establish the performance tuning goals and performance baseline. The difference between both is the performance gap which the process is targeted to eliminate.
While choosing the performance test scenario, we should also consider that different business scenarios would involve different portions of program code. If performance test case is not related to performance issue, then the “bad” code would not be traced. So it is critical to performance tuning process that a right performance test case is identified.
2. Performance tracing & Measurements
In this phase, with the help of performance tools, measurements & tracing for the scenario is done. The various traces and tools available are, ST30 for capturing the statistical data from STAD, ST05 trace for capturing SQL, RFC, Buffer, HTTP, Enqueque trace, SE30/SAT for the ABAP Trace.
While tracing any scenario, you should first execute the scenario twice or thrice in order to eliminate the buffering impact on performance.
If the scenario is too time consuming, you should do several traces at different time during the test execution instead of one trace.
3. Identifying Performance Issues & tuning opportunities
In this phase we need to analyze performance traces to identify the violations in ABAP logic or SQL operation
To pin point the problem in ABAP coding, we can analyze the SE30 ABAP trace, the major performance issues which causes the high CPU time are mostly inappropriate implementation of Internal tables either in terms of loop or read or sort.
If the DB Time of your application is high, we can refer to the SQL trace for getting to the root cause of the issue.
3.1 Analysis Steps for DB Time Analysis
3.1.1 Identical Selects:
Get into the ST05 trace and summarize it by SQL statements, now sort descending the column for identical selects. All the statements with identical selects value greater than zero can be the candidate for performance tuning.
The various issues due to which identical selects occur
1. Buffering not allowed on the table, solution can be to buffer the table according to the scenario, if this is not possible we could implement Buffer Module. Also, if the same data is fetched again and again we could append the data into an internal table on the first access to the data base and later read it from the internal table.
2. Buffering is allowed but bypassed, there are certain queries which bypass the buffer and hit the data bases. For eg.[refer the list below].
3. Buffering allowed but there is not data fetched by where clause and thus no records are found in the buffer and database table is accessed multiple times. Solution is to implement a No found buffer.
3.1.2 Buffer Bypass:
Arrange the column BfTp in descending order; the statements on the tables with buffering switched off will have this column as blank, if otherwise the statements are the candidate for performance optimization. Here we need to analyze why the buffers are bypassed and what can be done to avoid the same.
3.1.3 Proper Indexes
Arrange the Summarized SQL statements in descending order of time/execution.
If the time/execution of the statement is greater than 10ms, it can be the candidate for performance tuning. The various issues due to which this occurs:
1. No index is present on the table, which a where clause can use. Solution: if possible a new index needs to be created, or we can re-write the where clause in order to use the existing index.
2. The index is available, but the statement is written in such a way that is doesn’t use the index. For. Eg. A query with order by a,x,c whereas the table has an index a,c,x; such a query will not use the index . Solution: is to re-write the query in such a way it uses the index.
3. Insert/Update statements on a few tables might take a lot of time, which may be because the table has too many indexes and the time/execution also includes the time to update these indexes.
3.2 Analysis Steps for CPU Time Analysis
If the CPU time for the application is too high, the analysis can be done using the ABAP trace (SAT/SE30),
3.2.1 ABAP trace (SAT/SE30),
The SAT Traces help to identify hot spots in an application. This can be done by getting into the trace and sorting in descending order by net time. Here you may encounter issues due to
- Expensive operations on internal tables
- Unnecessary calls to processing blocks or entire code branches
- Long running modularization units
- Nested loops
3.2.2 Volume Scalability Single User Check
The major performance issues occur in an application when it handles large volume of data, (Customer like data), such huge data volume scenarios are generally difficult to simulate and analyze for the flow of data.
But, the SAT Runtime Analysis tool provides the option of testing the scalability of the application without creating huge volume of data. This is done by comparing the traces of the same scenario where different amount of data is handled.
This tool displays the comparison of various statements in both traces with respect to data processed in the statement/call and the net time taken by it, if both of these are in the same ratio then the application is scalable else that statement/call is the candidate for performance tuning.
Mostly these issues are due to the erroneous implementation of the internal table for e.g. sorting each time after append, using different & multiple sort order for an internal table etc.., which can be easily analyzed using the debugger.
3.3.3 Roundtrips & Network Delay
If the application has roundtrips of more than 2, the CPU time as well as response time would be high depending upon the location of your test system & server, due to network delay.
In SAT trace you can analyze the same, the net time of event RFC wait would be high and could be located in the SAT trace, or else the flush call could be searched in the trace.
Such calls directly for the application programs should be avoided.
4. Performance Tuning, Re-test & Analysis
In this phase the solutions need to be implemented to improve the performance.
If testing shows that program performance with the change is still short of expectation, you have to repeat the whole process again. It is important that we should execute the same test scenario and in the same SAP system with exactly same data before and after the change. Using different testing box is just adding another variable which makes performance measure harder.
SAP transaction SCI known as “SAP Code Inspector” can be used to scan through ABAP code to identify common performance pitfalls like SQL statement without where-clause etc. This is a static performance check. Output from this can be a part of improvement proposal together with what from trace analysis. Static code check is relatively simple is a good habit to use SCI.
- SAP Managed Tags:
