[SAP] ABAP Meter 관련 Notes

http://devops.sdsdev.co.kr/confluence/display/TechRepo/%5BABAP%5D+ABAPMeter

 

2879613 - ABAPMETER in NetWeaver AS ABAP

Version 5 from 2020.07.18 in English

 

Symptom

You want to test the general performance/health of each instance in a NetWeaver AS ABAP system.

You want to understand the purpose of the ABAPMETER in NetWeaver AS ABAP.

Image/data in this KBA is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental.

Environment

 NetWeaver Application Server ABAP

Cause

1. What is the ABAPMETER?
   
   
2. What is ABAPMETER actually measuring?
   
   
3. What are the threshold values for measurements in ABAPMETER?
   
   
4. When should ABAPMETER be used?
   
   
5. What can be done when ABAPMETER shows different measurements between instances?
   
   
6. What can done when ABAPMETER shows inconsistent response times?
   
   
7. What causes high values in "Acc DB" and "E Acc DB"?
   
   

Resolution

This document assumes there are no resource bottlenecks in any instances. (CPU, memory, etc.)
A resource bottleneck in an instance can negatively affect all ABAPMETER measurements for that instance.

1. What is the ABAPMETER?

ABAPMETER is a program which measures the execution time of various ABAP operations.

ABAPMETER is accessed through Transaction ST13 -> perf_tool -> ABAPMETER.

 

The results are displayed in a table with each row corresponding to one instance, and each column representing one measurement:

2. What is ABAPMETER actually measuring?

The specific ABAP operations executed by ABAPMETER are contained in program /SSA/CAT in the subroutines starting with names AM_*

 

For example, "Acc DB" is measured in the AM_SELECTS subroutine:

 

Which consists of 200 (non-buffered) selects on table T100.

3. What are the threshold values for measurements in ABAPMETER?

It is impossible for SAP to recommend hard thresholds as the results of ABAPMETER are influenced by many factors from hardware to virtualization and will vary from system to system (and instance to instance), but in general the following should be expected:

Measurement	Should be less than... (ms)
Bsc ABAP	100
Acc DB	150
E. Acc DB	150
(R)FC_PING	100
RFC_PING	300

Exceeding these thresholds slightly is tolerable, only when a measurement is significantly greater than the above thresholds should special attention be paid to that particular type of ABAP operation.

For example, the following shows concerningly high DB response times only on instance xxxxxxxxxxxxxxx_02:

 

For high values of "(E.) Acc DB", see what causes high values in "Acc DB" and "E. Acc DB"?

4. When should ABAPMETER be used?

ABAPMETER cannot tell you exactly what is wrong, but it can potentially show a problem exists processing ABAP. ABAPMETER measurements should be checked in the following situations:

The performance of some instances are worse than others. (For example: a job takes longer when executed on particular instances)

This includes comparing instances from different NW AS ABAP systems.

For example:

(ABAPMETER results from a heterogenous system landscape. That is, instances _04, _05, and _06 are running on different hardware and Operating Systems.)

ABAPMETER shows that instances _01, _02, and _03 outperform instances _04, _05, and _06 in almost all measurements. ABAP is simply executed slower on instances _04, _05, and _06.

Also note that all the measurement of instances _04, _05, and _06 are generally within the thresholds listed in what are the threshold values for measurements in ABAPMETER? .

Here ABAPMETER is being used to show a systemic difference in performance of different instances.

See what can be done when ABAPMETER shows different measurements between instances?

The performance of a particular instance is inconsistent (good at times, poor at other times)

When executing the same transaction/report/job on the same instance and the response time is not consistent, this may indicate a problem in the infrastructure below SAP.

To test this, execute ABAPMETER repeatedly and compare measurements from the same instance over a period of time.

For example:

(Multiple ABAPMETER executions in the same system taken 30 seconds apart.)

ABAPMETER shows that there is variance in simple ABAP tasks such as reading an internal table and calculating integer values.

Such variances should not exist in a well-performing system.

Here ABAPMETER is being used to show instability in the infrastructure below SAP.

See 6. What can done when ABAPMETER shows inconsistent response times?

5. What can be done when ABAPMETER shows different measurements between instances?

• Are both instances running on identical hardware?
• Are both instances virtualized? (or neither virtualized?)
• Are both instances running on the same Operating System with identical configurations?

If the answer to any of the above is "No" then the two instances cannot be compared directly. Performance differences due to a heterogeneous system landscape must be managed by the customer.

SAP certifies different combinations of hardware, virtualization solutions, and operating systems. Though these combinations are certified, their performance may differ.

• Are "Acc DB" and "E. Acc DB" the only measurements that differ?

See what causes high values in "Acc DB" and "E. Acc DB"?

• Do both instances pass the precheck report ZRS_ABAP_STMNT_PERF_PRECHECK from SAP Note 2677809 ?
• Are all traces in both instances turned off? This includes:
• SM50 -> Administration -> Trace -> Active Components : any component set to level 2 or 3 can retard execution.
• ST01
• ST05
• ST12/SAT/SE30
• Hana client traces : DBACOCKPIT -> Configuration -> Trace Configuration -> SQLDBC-Trace

Before comparing instances, ensure they both pass the precheck report and that all unnecessary traces are turned off.

6. What can done when ABAPMETER shows inconsistent response times on the same instance?

If the inconsistency is only in "Acc DB" and "E. Acc DB", see what causes high values in "Acc DB" and "E. Acc DB"?

If the inconsistency is also in any of the following measurements:
|Bsc ABAP|Sort i.t.|Cp int tbl|Read Table|Calc. int.|Calc. real|Read SORT|Read HASHE|P. Read HA|P. Read SO|1 Step Del|3 Step Del|Ins. SORT|Ins. HASH|Nat. Join|Par. Join|Nest. Loop|Par. Nest.|

Then further investigation must be done by the vendor/teams responsible for the infrastructure below the SAP instance.

As the amount of code executed by ABAPMETER is fixed, any variance in these measurements is not caused by the SAP instance or the ABAPMETER program itself.

7. What causes high values in "Acc DB" and "E. Acc DB"?

In nearly all cases, high(er) values in "(E.) Acc DB" are caused by network, specifically the round trip times (RTT) between the SAP instance(s) and the DB.

The team responsible for the infrastructure must ensure the environment is free of network errors and that the RTT between SAP instances and the DB are consistently below the required thresholds per What are good values for throughput and roundtrip time? in SAP Note 1100926 :

• <= 0.3ms : Recommended
• <= 0.7ms : Acceptable
• >  0.7ms : Tuning advised

SAP cannot help with reducing RTT or troubleshooting network errors (unless the system is hosted in a cloud environment managed by SAP).

For Azure environments, see SAP Note 2931465.

See Also

 2931465 - Reduce network latency (RTT) using Proximity placement groups on Microsoft Azure

Keywords

 Azure, RTT, round trip time, ST13, perf_tool