011000358700000237112013 e

8/13/2019 011000358700000237112013 e

http://slidepdf.com/reader/full/011000358700000237112013-e 1/35

HOW TO VERIFY

PERFORM NCE

REQUIREMENTS FOR

YOUR DEVELOPMENT

PROJECTS M NU LLY

IN NETWE VER B P

Document Version 1.1

March 2013

8/13/2019 011000358700000237112013 e


Typographic Conventions

Type Style Description

Example Text Words or characters quoted

from the screen. Theseinclude field names, screen

titles, pushbuttons labels,

menu names, menu paths,

and menu options.

Cross-references to other

documentation

Example text Emphasized words or

phrases in body text, graphic

titles, and table titles

Example text File and directory names and

their paths, messages,

names of variables and

parameters, source text, and

names of installation,

upgrade and database tools.

Example text User entry texts. These are

words or characters that you

enter in the system exactly as

they appear in the

documentation.

<Example text> Variable user entry. Angle

brackets indicate that you

replace these words and

characters with appropriate

entries to make entries in the

system.

EXAMPLE TEXT Keys on the keyboard, for

example, F2 or ENTER.

Icon Description

Caution

Note or Important

Example

Recommendation or Tip

8/13/2019 011000358700000237112013 e


1

Document History

Document Version Description

1.00 First official release of this guide

8/13/2019 011000358700000237112013 e


Table of Contents

1 Introduction ............................................................................................................................... 3 1.1 Planning tests ............................................................................................................................. 3 1.2 Determine the bread-and-butter processes ................................................................................ 3 1.3 Running Single user tests ........................................................................................................... 3

1.4 KPI’s and Best Practices for performance optimized programming ............................................ 4 2 Verifying recommended architecture characteristics ........................................................... 5 2.1 How to check the number of unnecessary accesses to the persistence layer ............................ 5 2.2 How to check Indexes............................................................................................................... 10 2.3 How to check parallel processing ............................................................................................. 12 2.4 How to check programs for nonlinear scaling behavior ............................................................ 14 2.4.1 Processing time / CPU .......................................................................................................... 14 2.4.2 Memory ................................................................................................................................. 15 2.5 Server-to-server roundtrips ....................................................................................................... 16 2.5.1 JCO and RFC specific information........................................................................................ 16 2.5.2 HTTP specific information ..................................................................................................... 17 3 Measuring recommended Performance KPIs ...................................................................... 18 3.1 Number of accesses to the persistence layer ........................................................................... 18

3.2 Measurement with the Statistical Records Monitor ................................................................... 19 3.2.1 Mobile application ................................................................................................................. 21 3.3 Data volume (net value in KB) transferred to and from persistence layer ................................. 23 3.3.1 Example: Mobile Application – NW Gateway ........................................................................ 23 3.4 Peak memory consumption (MB) ............................................................................................. 24 3.4.1 Example: Mobile Application – NW Gateway ........................................................................ 24 3.5 CPU consumption (msec) ......................................................................................................... 25 3.5.1 Example: Mobile Application – NW Gateway ........................................................................ 25 3.6 SAP GUI-based front ends: End-to-end Response time, Roundtrips, front end network traffic 26 3.6.1 End-to-end response time .................................................................................................... 26 3.6.2 Number of round trips between frontend and application layer ............................................. 27 3.6.3 Data volume transferred between frontend and application layer ......................................... 28 3.7 Browser front ends: Response time, roundtrips, network load .................................................. 28

3.7.1 Example: Mobile Application –

NW Gateway ........................................................................ 29 4 Further Information ................................................................................................................ 32

8/13/2019 011000358700000237112013 e


3

© 2013 SAP AG. All rights reserved.

1 INTRODUCTION

This document describes how you can manually check performance KPIs in NetWeaver ABAP of your

development. The document focuses on obtaining the proper values only, not on performance analysis or

optimization. The document is targeted at people with little experience in using SAP performance tools.

1.1 Planning tests

The pure planning phase probably is also the most time-consuming one. The more experience the projectteams have in setting up and running tests, the less time they need, obviously.

1.2 Determine the bread-and-butter processes

There are basically two sets of performance requirements: user-driven and throughput-driven. In the firstexample you analyze the system from an end user perspective, considering perceived performancerequirements as well as system performance requirements. In the second case response time is negligible.Here, you test the nightly background jobs where hundreds of thousands of data items need to beprocessed in a few hours, or where several processes are interdependent on each other.

Tip: Try to reduce the number of processes as much as you can. Five to ten should be sufficient as it isbetter to define a few scenarios well than have many ill-defined scenarios. There are mainly two reasons forthis: keep the complexity at a minimum. Also, the test cases need to be scripted and analyzed from differentperspectives.

Examples for bread-and-butter processes:

Client A planned to include a single-sign on authorization check in their corporate portal. For themthe end user response time for this process was very important.

Client B ran several different systems and applications within one process chain. Their critical pathanalysis determined that the full order processing had to be completed within 15 minutes or elsethey would run into severe business problems.

Determining the bread-and-butter processes sometimes is a trade-off as well. In addition to asking theapplication owners, you can also make use of the legacy system to understand the core business processesand critical applications.

1.3 Running Single user tests

One basic principle for achieving meaningful performance results is to let the system warm up with pre-runs.This fills buffers and caches and in general minimizes the influence of artifacts. The rule applies to single-user tests and load tests alike. The advantage is that the results will be reproducible, a very important factorfor performance analysis and regression testing.Pre-runs also bear the advantage that you can still check if there are any functional issues with the testcases. However, you could also decide to measure the performance of a “cold” system, because a cold startshows non-optimal programming on first access of the applications (optimization potential). This couldbecome critical in situations where you cannot increase buffers and caches due to hardware limitations andeviction of cached data is necessary or cached content simply expires. By having the system restartedautomatically by the load testing environment just before the load generation is triggered, you can get areproducible initial state of all buffers and caches. On the other hand, these results are not reproducible andshould not be used as a basis for regression testing. It is important that you understand the implication ofeach method for your test results.

8/13/2019 011000358700000237112013 e


© 2013 SAP AG. All rights reserved © 2013 SAP AG. All r ights reserved 4

A single user test refers to one user clicking through a series of screens entering data as required whilethese activities are being performance-monitored. Of course the test can also be automated. However, theimportant aspect here is a manageable well-defined test scenario. A unit test describes roughly the same,where a huge background application is split into smaller jobs for an initial analysis.These tests can also run in a smaller test system, you do not necessarily need the complete load testinfrastructure for these kinds of tests. Whichever system you will use, for optimal results make sure you

have the system all to yourself so only your activities are captured.If you really cannot be alone, then at least make sure there are no background processes, and that theCPU utilization is below 10%.If there are serious time restraints, you can capture only the performance KPIs (such as the number ofdatabase accesses, amount of data retrieved, CPU time per step, peak memory consumption, numberof roundtrips to front end and between two servers and transferred kilo bytes to front end).

In a second step you can analyze the quality of the database accesses (index design, identical selects,memory allocation, quality and quantity of cached data, and so on) and remove bugs. These findings canthen be returned to the application team which is responsible to modify the application software, asappropriate.

1.4 KPI’s and Best Practices for performance optimized programming

Derived from the performance design patterns you could for example use the following KPIs in performancetests carried out by developers themselves, and for quality check points and regression tests run by qualityteams.

Check the number of unnecessary accesses to the persistence layer

Check Indexes

Check parallel processing

Check programs for nonlinear scaling behavioro Memoryo CPU

Minimize Front end to server or Server-to-server roundtrips

Many performance issues cannot be solved by fixing a simple bug in the software code alone. They arecaused by inappropriate design decisions made in the software architecture. Performance design patternsspecify target behaviors and design rules for software components and interfaces while at the same timeallowing a high degree of freedom for the implementation. A SAP business application generally consists of3 layers: the persistence layer, the application layer, and the front end layer. Relational database systemsare typically used in the persistence layer, and the data accesses are executed by so-called SQLstatements. While the persistence layer has to ensure the data consistency under highly concurrent dataaccesses, the application layer carries out CPU intensive processing of business logic. The application layerof a large software system is typically built up by a load-balanced cluster of application servers, which scalein CPU and memory and provide high availability at the same time. The front end layer represents the userinterface (UI), typically running on PCs, connected by a LAN or WAN to the application servers, providing

high usability and productivity to the end users.

8/13/2019 011000358700000237112013 e



2 VERIFYING RECOMMENDED ARCHITECTURE

CHARACTERISTICS

2.1 How to check the number of unnecessary accesses to the

persistence layer

There are basically four different types of statements that unnecessarily access the persistence layer, tables

that are not needed at all for the business process at hand, statements that bypass the different types of

buffers on the application server (mainly the table buffer and nametab buffers), incomplete where clauses

and identical accesses within the same business transaction retrieving the same information multiple times.

There is an additional type of error when it was forgotten to set the right buffering flag for tables or views

which contain rarely changed data such as meta data or customizing data. This fifth type of error cannot be

detected by looking at the SQL statement, but by looking at the technical setting of the table or view.

Because accessing the database is always very closely linked to the business process, fully automated

verification will never be possible and is also not intended. However, you can make use of some tools that

help you to cast light on possible areas for improvement. These tools can help you in the decision makingprocess, they cannot make the decision for you.

To check you would look for two separate indicators:

the number of executions and

the runtime of the accesses.

Procedure:

1. For an overview of the SQL statements use the Performance Analysis (SQL Trace, transaction ST05).

For further information please check:

The SQL Trace (ST05) – Quick and Easy

Help Portal: Global Performance Analysis

2. Summarize the trace according to SQL statements (as of NetWeaver 7.02/7.20 in the menu Trace List

Summarize Trace by SQL Statement).

For the purpose of this documentation we use a somewhat artificial example, please do not over

interpret the figures and thus the findings. In this exercise, the total number of executions is

assumed at 106 and the total runtime at 59,008 micro seconds:

http://scn.sap.com/community/abap/testing-and-troubleshooting/blog/2007/09/05/the-sql-trace-st05-quick-and-easy



http://help.sap.com/saphelp_nw73ehp1/helpdata/en/44/c84e0cc84b5478e10000000a422035/frameset.htm




8/13/2019 011000358700000237112013 e



Figure 1: Summarized SQL Statements in ST05

3. Check the 5 different types of performance bugs/improvements for in the category “unnecessary DB

accesses” and determine the fraction of the DB request time which can be saved by optimizing your

code.

For the purpose of this documentation we use a somewhat artificial example, please do not over

interpret the figures and thus the findings. In this exercise, 32% of the total DB request time or 19,021

mircosec can be saved.

a. Check that no buffered or customizing data is read from persistency. Filter column Buffer type(BfTp) according to filter criterion “non-initial” to see which statements access buffered data or

customizing data:

8/13/2019 011000358700000237112013 e



Figure 2: Filter criteria, select “unequal empty”

The system then displays statements which retrieve data from the DB,

although it is buffered in the table buffers (BfTp=SNG, GEN, FUL) Rewrite the statements to use table buffers

although it is buffered in the so called nametab buffer(BfTp=DDIC) and can be retrieved via the

official DDIC interfaces to buffered runtime data and

User DDIF_FIELDINFO_GET, DDIF_NAMETAG_GET, look at the documentation of the

function module used by your coding to see alternatives recommended there

although it is data which very likely should be buffered (BfTp=DESNG, DEGEN, DEFUL, CUST). Consider changing the buffer settings in the technical settings of a table

To see how many executions are unnecessary, look at column Executions. In this example 24

unnecessary executions with a total runtime of 8,591 micro seconds are caused by non-buffered

accesses that should not go to the database layer at all.

Figure 3: Filtered SQL statements

8/13/2019 011000358700000237112013 e



b. Check if only those tables are read that are really needed for the business application. First change

the filter on column Buffer type (BfTp) according to filter criterion is “initial” to exclude those

statements that were already covered in the previous check.

In column Object name check the tables that are being read. Ensure that only those tables are

being read that are needed for the business process. Examples for tables that are unnecessary are: The address data of a business partner when you only need the name.

Items of a document when only header information is needed

…

Figure 4: Checking for business relevance of access

This analysis cannot be automated and you need application knowledge to understand which tables

can be removed. Depending on the number of accesses, removing these tables can save

considerable CPU cycles. To identify the runtime of the tables, take the according runtime. In the

sample test assume that all tables have to be read because the data is needed with one exception:

The data of table FIAD_GL_ACCT is not needed. There are 2 executions with a runtime of 822microseconds.

c. To identify the runtime of unnecessary accesses caused by identical selects first exclude the tables

identified in the previous check by using the filter on the object name. Additionally, you should set a

filter on column Redundancy, so the system displays the lines with redundant accesses. In column

Redundancy you can see the number of unnecessary executions, 23 in total in this example.

8/13/2019 011000358700000237112013 e



Figure 5: Checking for identical selects

To obtain the runtime caused by these unnecessary identical executions, take the relevant

percentage of the identical accesses. Finally sum it up:

90% of 3,748 micro seconds = 3,373 micro seconds

89% of 3,318 micro seconds = 2,953 micro seconds

Do that for all statements. In sum, 9,180 micro seconds are superfluous in our example due to

identical accesses

This method delivers only a part of the identical accesses. It marks entries as identical only if the

complete WHERE clause is identical, when you look at it is as string. If the WHERE clause of one

statement looks like WHERE fieldA = valA and fieldB = valB and the WHERE clause of another

statement just turns it round WHERE fieldB = valB and fieldA = valA then these two statements are

not detected as being identical by the SQL Trace, although they are looking at the same result set.

Therefore it is a good idea to sort the unfiltered SQL trace summary by column Object name. If the

same object name appears multiple times you can manually compare the statement whether it is in

fact an “identical access” which is not automatically recognized by the tool. If you find such

statements they have to be counted, too, and have to be added to the sum above.

Possible actions:

In case of repeated accesses from your own coding implement a Data Provider that buffers

data internally and provides the data buffered to the consumer

Try to use standard data providers from SAP if you read standard tables (for examplefunction module Material_Read etc.)

d. To identify how much runtime was caused by incomplete Where-clauses, use the summarized SQL

statements. First remove again the filter on the Redundancy column set in the previous check. Then

sort the list descending according to the number of records read. Try to find those tables where the

number of records does not fit to the expected number, when looking at the test case from the

business point of view (e.g. how many different products are used for the creation of a sales order

and how many records should therefore be read from the corresponding database table(s).

8/13/2019 011000358700000237112013 e


8/13/2019 011000358700000237112013 e



high value is an indication for a database access which is highly probably not supported by a proper

index. Use Explain on this statement to check the access path. Try to find a solution by rewriting the

select statement, changing an existing index, or defining a new index.

When testing with small amounts of data in the corresponding database tables, the above procedure

may not be completely reliable, because accesses times even without an appropriate index may be fast,

or the explain function may not use an existing (appropriate) index. Alternatively you can check the selects in the SQL trace with code inspector: From the trace list, choose

Goto -> Trace Analysis Using Code Inspector (Ctrl F3). If the code inspector results show errors for

“SQL Trace Check: Analysis of WHERE Condition for SELECT” or “SQL Trace Check: Analysis of

WHERE Condition for UPDATE and DELETE”, then the check is not ok.

Figure 7: SQL Trace Check in the Code Inspector

If your test cases can be automated, we recommend that you use the Global Performance Analysis

(transaction ST30 ). The Global Performance Analysis enables you to automate the required checks to a

high degree and delivers most of the required results for a test case in one go.

If the checks identify problems, correct them and repeat the checks.

8/13/2019 011000358700000237112013 e



2.3 How to check parallel processing

To check for parallel processing, proceed as follows:

1. Check the program for exclusive SAP locks.

To check for exclusive locks, use the Performance Trace (ST05) and here at least SQL Trace and

Enqueue Trace.

The Enqueue Trace shows the request and release of enqueues as in the example below.

Figure 8: Overview of enqueues in the Enqueue Trace

In column “Operation” you see the enqueues and dequeues. Dequeues may take place for a single lock

or for all locks set in a LUW (DEQ ALL).

Column “Statement” shows the lock argument, starting with “S” means a shared, “E” an exclusive lock.

Check for exclusive locks.

- There must not be exclusive locks in pure retrieval functions

- If there are exclusive locks on objects that were just created, you can discount them.

If there are exclusive locks on central objects, that may be accessed and locked by many LUWs in

parallel (for example master data), compute the duration between enqueue and dequeue (using the time

stamps) and the resulting maximal achievable throughput.In our example (Change delivery (VL02N) and post goods issue), there is an exclusive lock on object

ELIKP (which locks a delivery document, see definition in the Data Dictionary using transaction SE11).

The duration of this lock is 18 msec (14:21:02.067 msec – 14:21:02.085 msec). As this is a lock on a

(just created) document and not on a central object, this is ok.

For exclusive locks on central objects, e.g. master data, compute the locking time and the maximal

throughput.

In our example a material is locked for 533 msec (14:21:09.046 msec – 14:21:09.579 msec).. This

means that at maximum 1,87 processing units (transactions using the same material) can be processed

per second, thus 1,87*3600 = 6732 per hour.

2. Check the database operations for updates

Display the SQL Trace List in transaction ST05

8/13/2019 011000358700000237112013 e



Figure 9: Trace List in transaction ST05.

In the trace list look for locks set implicitly by INSERT, UPDATE, DELETE statements and for the next

COMMIT WORK which releases the locks .

(This does not apply for all accesses to tables VBHDR, VBDAT, VBMOD, which are needed for

communication with asynchronous update task).

- Determine the critical object/ table for your application

- Check if the order of first INSERT, then UPDATE is kept.

- If there are updates, compute the lock duration using time stamps of UPDATE and next COMMIT

WORK and calculate the maximum achievable throughput.

- In the above example (showing only the last part of a SQL trace (Change delivery (VL02N) and post

goods issue), we see UPDATEs of table VBBS as last operation before COMMIT WORK, so this is

ok. The duration of the implicit lock of the VBBS is 3 msec.

This means that 333 processing units (transactions) can be processed per second. So this lock

would restrict the maximal achievable throughput for this function to 333*3600 = 1.200.000 per hour.

During load tests you have the additional possibility to use

- SM12 to monitor the system wide enqueue situation

- ST04 (Lock Waits) to monitor system wide database locking situation- SM66 to identify work processes waiting for database locks

Note that ST04 and SM66 usually are not helpful in single user tests, as there will be no wait situations

usually.

8/13/2019 011000358700000237112013 e


8/13/2019 011000358700000237112013 e



Figure 10: Linearity

Simple performance bugs, e.g. caused by using inappropriate statements within one modularization

unit, can be found be using the Code Inspector tool. Use the Code Inspector (transaction SCI ) to search

for sequential accesses to internal tables, i.e. accesses that cannot be optimized by the ABP runtime

using an index or key. This check is called Low Performance Operations in Internal Tables. On the

“Information” part of the check possible solutions are explained.

Use the Code Inspector (transaction SCI ) to search for nested loops (if they are not hidden in different

modularization units) and for database accesses (SELECT, INSERT, UPDATE, MODIFY, DELETE)

inside of loops. Choose the following single checks within the Code Inspector: SELECTs in loops,

Changing database access in loops, and Nested loops.

2.4.2 Memory

An application is scalable only if it has no memory leaks. Performance measurements for an application that

has memory leaks show misleading results. The application will run slower over time.

Repeat the test case / function several times (for example 10 times), but stay within the same transaction. In

other words, do not clear the user context by starting the transaction with /n again. Using eCATT or the

scripting capability of the SAPGUI makes it very easy to execute such iterations automatically. Check

memory consumption for the repeated executions in the Statistical Records (transaction STAD). There must

not be any increase in memory consumption.

If you have found a memory leak in the step above, use the ABAP Memory Inspector (transaction

S_MEMORY_INSPECTOR) to compare the memory use of two memory snapshots. Take these snapshots

e.g. after the first and after the second execution of the test case. Depending on the size of the memory

leak, the differences will be better visible if you use a higher execution number (after the first and after the

11th execution, for example). The ABAP Memory Inspector creates a hit list of the memory increase and

makes it easy for you to find the responsible objects, such as internal tables, classes and instances of

ABAP objects, strings and anonymous data objects.

8/13/2019 011000358700000237112013 e



2.5 Server-to-server roundtrips

2.5.1 JCO and RFC specif ic inform ation

Use the Performance Analysis (transaction ST05 ), and select the RFC checkbox to trace the amount of

RFCs between servers and the data volume transferred. In current releases you have to count the numberof RFCs using the search or filter functionality, e.g. by searching for unique search strings such as the

server name, and divide by the number of dialog steps to get the average number of server-to-server

roundtrips per dialog step.

For RFC trace records the column “object name” contains the information on the communication partner.

Only entries with a non-empty “object name” are relevant, empty cells are representing local calls to the

SAP automation queue (which are cached are flushed later-on).

Entries that show your frontend PC – these are roundtrips to the frontend, not between servers – are even

more important. This type of round trips should be counted also following the same pattern and are subject

to the same restrictions. Please see chapter 3.6.2 “Number of round trips between frontend and application

layer”

Figure 11: Trace List

Recommendation: 2 round trips per user interaction step"


8/13/2019 011000358700000237112013 e



2.5.2 HTTP specif ic inform ation

Use the Performance Analysis (transaction ST05 ), and select the HTTP button to trace the amount of HTTP

connections between servers and the data volume transferred.

Figure 12: Performance Analysis - HTTP Trace.


8/13/2019 011000358700000237112013 e


8/13/2019 011000358700000237112013 e



The Executions column shows the number of accesses to the persistence layer per aggregated

SQL statement. The total number of accesses to the persistence layer is shown at the bottom of

this column.

In later SAP Web AS releases, COMMIT WORK statements are treated as database accesses. If

you are comparing the traces of two releases, make sure that you always count COMMIT WORK

statements as database accesses.

3.2 Measurement with the Statistical Records Monitor

Do the following to avoid distorted measurements:

Before starting the measurement with the Statistical Records Monitor (transaction STAD), execute your

scenario at least once to fill the buffers and to compile involved programs.

Do not execute the measurements for the abovementioned KPIs at the same time as the measurement

for KPI 1 (number of accesses to the persistence layer). The fact that the SQL trace is activated for the

measurement of KPI 1 will influence the measurements for the other KPIs, especially for the CPU

consumption.

To obtain meaningful measurement results for memory consumption:

Applications using classical dynpros stop the Easy Access menu running in the session in which you

want to perform the measurements. Enter "/n" once or several times in the relevant session. The Easy

Access menu has been stopped successfully if the screen with the Start SAP Easy Access button is

displayed.

As statistical data are always being collected you can use transaction STAD to display all transaction steps

of a user. However, you are only interested in those steps that are part of your scenario. For this reason, we

recommend that you set markers to help you identify the beginning and the end of the interaction steps

relevant for your scenario. Proceed as follows to obtain the statistical data of your scenario and mark the

relevant data:

1. Invoke any transaction (in the example below STAD, but do not perform any further steps in this

transaction. This single STAD call will mark the beginning of the relevant statistical data when you

display the results in transaction STAD later on.

2. Execute your scenario. When it has completed, wait a while until the SAP update task has finished, if

necessary.

3. To display the statistical data collected for your scenario, start transaction STAD again from the same

session. Narrow down the data to the relevant bits, as follows:

In the Filter Parameter settings, specify your user name or the user name used for asynchronous

processes, such as workflow or middleware processes.

If there are several application servers in the system, select the application server you have been

working on via Server Selection.

Specify the time interval during which you executed the scenario by providing the start time and

duration. (Note that depending on the system release, the default values for the starting point and

interval may be inappropriate.)

Select OK or press Return to list the statistical records of all transaction steps involved. The

relevant statistical data are displayed between two single calls of transaction STAD.

8/13/2019 011000358700000237112013 e


8/13/2019 011000358700000237112013 e



In this example, you see the first call of the transaction STAD as a marker for the start of the measurement,

followed by the traced transaction VA01 with dialog and update tasks. In this example

The end of the relevant measurement is identified by the second call of the transaction STAD.

5. Make sure that all expected user interaction steps are displayed in the list. If some are missing, you

may have specified an incorrect time interval.

Based on the data displayed you can now calculate the required performance figures as described in the

appropriate sections below.

3.2.1 Mob i le appl ication

The following architecture for mobile applications is characterized by a synchronous request and responsepattern initiated by the device. By exposing SAP Business Suite functionality as REST-based OData (OpenData Protocol) services, SAP NetWeaver Gateway enables SAP applications to share data with a widerange of devices, technologies, and platforms in a way that is easy to understand and consume.

Figure14: Architecture for mobile applications

As described above statistical data are always being collected and you can use transaction STAD (SAP

Netweaver Gateway and SAP backend) to display the request initiated by the device.

8/13/2019 011000358700000237112013 e



Note:

Please be aware that depending on your application an user interaction step initiated on the device can

result in several ODATA requests. This will lead to several statistical data records in STAD (Gateway).

Furthermore on Gateway one HTTP request can trigger multiple RFC calls which again will lead several

statistical data records in STAD (Backend).

To correctly interpret CPU and response times you would need to check the HTTP details and the RFCdetails if you want to analyze why the difference between CPU - time and response time might be high.

For the statistical data records in STAD focus on the user(s) that are configured for your application.

Figure 15: STAD (Gateway) for request initiated by the device

Figure 16: STAD (Gateway) for request initiated by the device – detailed view

As described in the previous chapter, we recommend that you set markers to help you identify the beginning

and the end of the interaction steps relevant for your scenario.

8/13/2019 011000358700000237112013 e



3.3 Data volume (net value in KB) transferred to and from persistence

layer

For the net data volume transferred to and from the persistence layer, add up the appropriate entries in the

column kBytes transferred . For the example shown in figure 2 below, the value is (2.8 + 49.4 + .. +127.9) =

1157.8 kB

Figure 17: Workload Statistical Records - kBytes transferred

3.3.1 Examp le: Mobi le Ap pl ication – NW Gateway

Figure 18: Workload Statistical Records - kBytes transferred

8/13/2019 011000358700000237112013 e



3.4 Peak memory consumption (MB)

The instructions below only apply to dialog processes, or to those batch processes that can be run in dialog

mode using transaction SE38. Currently there is no simple way of measuring memory for any type of batch

process. Proceed as follows to obtain the required performance figure:

1. Complete the steps described in section on preparing the measurements.

2. To obtain the peak memory consumption per user interaction step, add the values in the columns Max.

mem. in roll (kB), New allocated page mem (kB) and Max ext. mem in step (kB) for each line. Since we

are interested in the peak memory consumption, note down the biggest value of the sum.

Figure 19: Workload Statistical Records – Memory


Figure 20: Workload Statistical Records – Memory

8/13/2019 011000358700000237112013 e



3.5 CPU consumption (msec)

For the CPU consumption per user interaction step in milliseconds, refer to the column CPU time (ms) and

add all values of your scenario. For the example shown in figure 4 below, the value is 2460 ms

(=110ms+30ms+...+250ms+50ms)

Figure 21: Workload Statistical Records - CPU Time


Figure 22: Workload Statistical Records - CPU Time

8/13/2019 011000358700000237112013 e



3.6 SAP GUI-based front ends: End-to-end Response time, Roundtrips, front end network traffic

Nowadays network time can be a dominating part of the end-to-end response time while using WAN (Wide Area Networks), as network latency time and the time needed to transfer the data to the frontend addssignificantly to the end-to-end response time. For example, a synchronous round trip over a satellite couldadd 0.5 seconds to the total response time easily. The round trip time is even higher for mobile devices

which are connected via any type of wireless network. The conclusion is obvious: The more round trips theworse the application’s response time.In order to achieve good end-to-end response times, it is important to understand and optimize theunderlying network infrastructure. During development make sure that your application is optimized for lowbandwidth (small amount of data being transferred to/from the front end) and high latency (only 1-2 roundtrips per user interaction step). This ensures best possible response times.The recommendation is to have not more than 2 sequential round trips per user interaction step betweenfront end and application layer as well as not more than 2 sequential round trips between twoservers/instances.

3.6.1 End-to-end respon se time

There are several ways of checking the average end-to-end response time response time:

Display the detailed information of the status line of your SAP GUI for Windows, and select Response

time to display the response time permanently. Then, run your scenario and write down the response

time for each user interaction step. Add all response times and divide them by the number of all the user

interaction steps of your scenario to obtain the average dialog response time. This measurement

includes the network time and should not be used in case you access the system remotely.

Alternatively, you can use the Statistical Records (transaction STAD) to get the average dialog response

time. Ideally, both times should be very close. The SAP GUI dialog response time includes networktime, so in Wide Area Network connections this value will be much higher than the server response

time.

8/13/2019 011000358700000237112013 e


8/13/2019 011000358700000237112013 e



3.6.3 Data volume transferred between front end and appl ication layer

For the data volume, refer to the columns Terminal in-message, Teminal out-message and add up the

values for both columns for all user interaction steps. Only include transactions of the type D (dialog) in this

calculation. In the example shown in figure 5 above, the value is 99.8 kBytes (416 bytes + 116 bytes + … +

490 bytes + 12,854 bytes + 4,508 bytes + … + 4435 bytes). Divide the value calculated for the whole

scenario by the number of user interaction steps (in the example above there are 14 user interaction steps)

to obtain the required average value (6.5 KB in this case).

3.7 Browser front ends: Response time, roundtrips, network load

In case of browser front ends, currently the statistical records lack of information, because

they do not reflect end-to-end response time (front-end rendering time is missing)

the number of roundtrips is 0

o STAD can only provide information for a single roundtrip and has no knowledge about all

roundtrips associated to a user interaction step

o the data transferred may be incomplete, for example, in case of additional communication

with other servers

o Communication did happen only to the Internet Communication Manager (due to incorrect

cache setting of static MIMEs), which produces no STAD entry, as the ABAP layer was not

called.

You could use various browser plug-ins or network sniffer tools to analyze network communication (number

of roundtrips and amount of transferred data to/from the front end) like HTTP Watch, Live HTTP Headers

(Add-on for Firefox), Fiddler2, …

These are only examples and do not mean a recommendation from SAP.

Remark: For further analysis you could also check the http log from the Internet CommunicationManager. The Internet Communication Manager ensures that communication between the SAPSystem (SAP NetWeaver Application Server) and the outside world via HTTP, HTTPS and SMTPprotocols works properly. In its role as a server, the ICM can process requests from the Internet thatarrive as URLs with the server/port combination that the ICM can listen to. The ICM then calls therelevant local handler for the URL in question.

This enables you to retrieve the KPI “number of roundtrips per dialog step” and “amount of transferred data

per dialog step” also for http based UIs.

8/13/2019 011000358700000237112013 e




This behavior also reflected when a request is initiated by a device.

Figure 24: Number of round trips

Therefore you would have to use the mentioned tools above.

Further in format ion to analyze the mob i le appl icat ion:

8/13/2019 011000358700000237112013 e


8/13/2019 011000358700000237112013 e



that triggered 2 RFC calls to the SAP Backend.

Figure 26: RFC calls

8/13/2019 011000358700000237112013 e



4 FURTHER INFORMATION

Related Websites:

http://service.sap.com/performance

http://service.sap.com/sizing

http://service.sap.com/benchmark

www.sap.com/benchmark

Related SDN site:

http://scn.sap.com/community/performance-scalability

8/13/2019 011000358700000237112013 e


© 2013 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information

contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, System ads, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries,

pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture,

POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN,

DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Inform ix are trademarks or

registered trademarks of IBM Corporation.

Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United

States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein

as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other

product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposesonly. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for

informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the

materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such

products and services, if any. Nothing herein should be construed as constituting an additional warranty.

Date post:	04-Jun-2018
Category:	Documents
Upload:	srinivas-rentala
View:	217 times
Download:	0 times

011000358700000237112013 e

Documents