SAP performance testing & engineering courseware v01

SAP ERP Performance
Testing & Engineering
Courseware- V01
Designed & Created By: Suryakanth Kelmani
Sr. Architect - Performance Testing & Engineering
Author:
I have been working in the performance testing & engineering for the past 12 years in large projects
like SAP, Oracle eBusiness, Java Documentum, Siebel, IBM WCS eCommerce and other technologies.
I live in London with my wife and a lovely son. I dedicate these slides/document to my parents and
my family members for supporting during the period of creating this document design and creating
the slides.

Table of Contents
Session -1
Quick glance at SAP System
Architecture
SAP Modules
SAP T Codes
What is iDOCS
Why SAP Performance testing
When to test and what to test in SAP Performance
testing
Lab Exercise – Familiar with SAP application
Session -2
Planning Phase
Methodology example
Critical Scenarios from modules
Test Data Management
Performance Test Environment Setup
Monitoring tools
Lab Exercise - Familiar with Modules & Planning
Session -3
Scripting Best Practices
Correlation for SAPGUI & SAP Web
Use of SAPGUI functions
Script enhancement & error handling
Coding standards
Lab Exercise
Session -4
Execution & Monitoring
Smoke test
Script verifications with data
Monitoring setup verification & Log enable
Scenarios calibration & run time settings
Performance test execution readiness
Lab Exercise – scenarios Design & Executions
Session -5
Analysis & Tuning Best Practices
Analysis process
Performance Stats analysis
Prepare interim test report for each tests
Provide recommendations & Suggestions for tuning
Lab Exercise – Analyse the LRA report
Session -6
Knowledge Management
Lesson learnt
Issues and resolutions
Other information

SAP Performance Testing
Objective
The objective of this courseware is to quickly implement the best practice guidelines & approach for SAP
performance testing ( Both SAPGUI & SAP WEB client/protocol )
Learn quickly to configure & Setup the SAP application server parameter with HP Loadrunner tool capture the
SAPGUI traffic.
What must be included in scope for SAP performance testing.
Learn how Correlation in SAP GUI is different from other protocols.
Best practice guidelines for scripting, execution, Monitoring and analysis.
At the end of each session, the candidate is expected to complete the lab exercises.
Note : This course is designed for those who has earlier involved in performance testing projects and executed at
least 2-3 projects independently.

Session -1
Quick Glance at SAP System

Session-1Session-1
Following are the topics which will be discussed during this session
Quick glance at SAP System and Architecture
SAP Modules
SAP T Codes
What is iDOCS in SAP and How to create iDOCS
Why SAP Performance testing
When to test and what to test in SAP Performance testing
Lab Exercise – Familiar with SAP application

SAP Client Server Architecture
Presentation
Layer
Application
Layer
Database
Layer
Client 100 Client 200 Client 300 Client 500
SAP Clients
SAP R3
Application Servers and Central Instance CI
Database Server
Work Processes – Dedicated SQL *Net Connections
Oracle
Database
SAP GUI & Web user
PS: Have explained in the notes below about each layer in detail
The ERP software application from SAP helps to improve operational efficiency and
productivity of business processes of the enterprise
Work Process-1
Work Process-2
Work Process -3
Session-1Session-1

SAP Client Server Architecture Continued...
SAP R3 supports a three tier client server architecture. The three layers of the client server architecture
in the SAP R3 system are:
Presentation Layer: Consists of a PC based graphical user Interface (SAP GUI or SAP Web).
Application Layer: Consists of the SAP application servers that service the requests for Data &
Manage the interface of the presentation layer. The application layer of the SAP system consists of
application servers and message servers. The application server use the message server to
communicate with the presentation components, database server and with each other. All data is
stored in centralised database server.
Database Layer: Consists of the actual Database Management System (DBMS) that communicates
with the application servers and provides the data requested by those servers.
Note that the above client numbers (mentioned in slide #5) like 100, 300 or 500 refers the SAP client
from which you will be logged into the SAP system, each env will have different client allocated, for ex
client 200 may be assigned to QA ENV, 500 may be for Pre prod, client 100 assigned to Sand Box etc.

SAP Architecture Continued...
SAP is an ERP product which seamlessly integrates the different modules/applications in a business such as Sales &
Distribution, Finance, Production etc without sacrificing the convenience of the integrated system.
Note that the CI ( central Instance ) in sap system is a combination of h/w & s/w which contains the a physical server ( App
Server ), this also called as SAP ECC (ERP Central Component)
The CI also includes other s/w components like Message server & Database gateway, in most of the SAP architecture,
there are numerous app servers but only single CI.
Within ERP SAP package there are many applications as shown below, these are standard to specific industry solutions, for
example IS U Industry Specific to UTILITIES (IS-U), IS-OIL for oil companies, IS-T for telecom sector, IS-B for Banking and
IS-Retail for retail sector.
Material Management (MM)
Order to Cash / Sales & Distribution (OTC/SD)
Human Resources/HCM ( ESS/MSS/eRecruitment etc)
SCM
SAP user log into SAP system by using a PC based GUI called SAPGUI also using browser for SAP web client.
After login, the end users are connected to a specific application server which has pre established connect with the
database server.
To execute any of the transaction in SAPGUI, the user will use the transaction code called T Code, transaction codes are
short path to a specific screen in SAP, for example VA01 transaction code brings you to the create sales order screen, few
more examples are shown below
/nVA01 for creating the Sales Order
/n VF01 Creating Invoice
/n VA03 Display customer Order etc..
Note : /n is a shortcut for exiting the system/Function
SRM
Finance & Costing (FICO )
Production Planning etc.
Master Data Management (MDM)
Session-1Session-1

What is iDOC in SAP
IDoc or Intermediate Document is a standard SAP document exchange format. IDocs allow different
application systems to be linked via a message-based interface.
The IDoc interface consists of the definition of a data structure (where the data structure is the IDoc)
and a processing logic for this data structure. There are three main aims behind the use of IDocs
1. The structured exchange of business documents so that they can be processed
automatically.
2. The various degrees of structural complexity as displayed by different application systems
can be reduced to a structure which is as simple as possible.
Example: The structure of an SAP application document and the structure of the
corresponding EDI message under the UN/EDIFACT standard.
3. IDocs allow for extensive exception handling before the data is posted to the application.
The following data can be transferred using the EDI interface:
Outbound IDocs: IDocs are transferred from the SAP system to the EDI subsystem.
Inbound IDocs: IDocs are transferred from the EDI subsystem to the SAP system.
Status report: The EDI subsystem sends a status report to the SAP system on the progress of
the processing of the outbound IDoc.
Note that, iDOCS can be created either using tools or by ABAP program ( help can be taken from
ABAP/Functional team to create the required volume of iDOCS.
Session-1Session-1

Why SAP is different to other applications
Its an Enterprise Resource Planning tool
Its has both clients ( Thick & Thin clients)
Refer the architecture diagram for the details.
More ...
Problematic Areas or usual suspects
Customization ( ABAP code issues)
Configuration (Load balancing, Application, OS and Database level)
Patch Levels
Environment Sizing
Negative of SAP
ABAP developers tend not to think of Performance.
No help from SAP support on custom code developments
Positive of SAP
Scripting is usually easy.
Architecture is proven & SAP code is mature
Large Database of performance patches & tuning tips.
Session-1Session-1

Why SAP Performance Testing
To ensure SAP implementation/rollout complies to NFR (non-functional requirements ) at both individual business
transaction level and system/infrastructure level
Identify & remove performance
bottlenecks in individual
transactions, Batch Jobs &
Interfaces
Determine system scalability
under various load conditions
Improve ABAP code in SAP
Fine tune the h/w & s/w configuration
Fine tune the database queries
Reconfigure the business process
Measure KPIs at reasonably
Expected peak load/volumes (100%
scenario).
At increased load/volumes (120% Scenario)
Understand the impact of peak load processing times by
simulating the exact business processes on performance
test environment ( pre prod env) before go-live
Session-1Session-1

When to Test?
Its is recommended to involve the PT team in the early phase of SAP implementation to quickly
identify and analyse the performance areas.
Make sure that there is no overlapping of SIT with PT, as you face this situation in many projects due
to tight timelines, but set the expectations clearly and risks involved.
We will discuss more in Planning.
Session-1Session-1

What to test in SAP ?
What uses the SAP system resource
Online Users performing various critical business transactions/T codes
Data Processing online & Batch jobs/Interfaces and critical reports
Identify the peak usage period and simulate the peak usage load with online users & batch jobs/Interfaces
Users Executing
Online transactions
Inbound Interface to SAP
system from 3rd party
Outbound Interface from
SAP system to 3rd party
Batch Jobs scheduled in
Scheduler and run in SAP
Session-1Session-1

What to test in SAP Performance testing
Note that we can’t ignore the batch jobs/interfaces for the performance testing as these will
contribute major performance issues in the system. You must include the following for the
performance testing scope..
Batch Jobs/Interfaces & Reports
Batch Jobs with high volume records for day/night production setup
Interfaces which are To/From SAP system (Inbound/Outbound Interfaces)
Heavy reports
Interactive Business Processes
Online Users (i.e. Various T codes identified in NFR)
Enterprise Portal Users (ESS & MSS)
Business Intelligence (BI) only Web based reports not Bex Analyzer since these are excel
based Macros and LR does not support this.
Sociality between these areas under load ( Mix of both )
Combine both Online users & Batch jobs/Interfaces/Reports together.
Note that All the above business process should be selected based on the following criteria
High Frequency transactions
Business critical transactions
Transactions which are data intensive ( READ/UPDATE transactions)
Session-1Session-1

Lab Exercise
This completes the end of session -1 , after this session the candidate should get familiar with
SAP system, architecture, various client /instance allocated to different teams like Dev, SIT, PT and
UAT etc.
Use the SAP lab to logon to the SAP system through SAPGUI client with the following details..
a. Username : KELSUR
b. Password : *****
c. Client :200
d. Language :EN
e. Navigate around the application using various T codes
Create Sales Order using VA01 T code
a. Type VA01 in the transaction code field ( at the upped left corner of SAP window)
b. Click on ENTER button
c. Fill in all the required fields with the data
d. Click on SAVE to create the sales order in SAP SD module
e. Keep a tab on the each steps and observe what is happening in SAP system
f. At the end of the screen below left corner you can see order number created successfully
g. Continue to work on SAP with various T codes like VA02, VF01 etc.
OUT COME : At the end of this session the team should be able to understand the SAP architecture, system modules, T codes,
navigation flow etc.
* Note that user name, Password and Client number will be depend on the environment on which you guys are doing the exercise
ask your team to provide these details during the lab exercise.
Session-1Session-1

Session -2
Planning Best Practice

Session-2Session-2
Following are the topics which will be discussed during this session.
Methodology example
Critical Scenarios from modules
Test Data Management
Performance Test Environment Setup
Monitoring tools
Lab Exercise -

SAP Performance Testing - Planning
The objective of this session -2 is that the resource will be able to
To define and quantify the performance testing objectives for the SAP system performance
testing
Derive the work load model/transaction volumetric model( non functional requirements ) by
identifying the critical transactions which we can performance on SAP application under test.
Identify the source of test data required for performance testing
Test environment Setup activities
Identify the stakeholders and setup the expectations
Identify the risks, issues, dependencies which should help to pen down the performance test
plan & strategy
Session-2Session-2

Back to Basics
#1 Rule: Employ the KISS Methodology ( Keep It Simple & Structured )
Remember that we are validating performance, not functionality of the SAP system
Test to the requirement and cover all critical requirements in order to carry out the end to end performance of
entire SAP landscape and 3rd party applications integrated with SAP.
Set and Manage the client expectations religiously.
Remember that we are here to find performance problems/issues, be excited when we find the bottleneck but
be positive with the right data points and analysis.
Highlight the Dependencies, Risks, Issues and discuss the same with the project team & stakeholders to reduce
the impact on the go-live schedule.
Document the defects in the defect tracking tool or in QC, follow up the defect till closure
As a best practice and minimize the project risk and timelines, I strongly recommend performance testing team
should involve at early stage of implementation phase, work shops should be conducted along with SAP BASIS,
ABAP team & Functional teams to understand the test data, environment and other requirements which is always
been a problem for PT, this will definitely help us to create the required data through automated scripts and
minimize the risk proactively .
Session-2Session-2

During this phase, I strongly suggest performance testing team to work with project stakeholders/project manager,
business/process owners, technical team, BASIS and Infrastructure team to set the expectations, define scope, test env
requirements, Test Data Management, dependencies etc.. Following activities should be carried out during this phase..
Define the performance testing objectives
Define performance testing methodology & process aligned with the client’s SDLC followed in their program.
Gather and Analyse the performance requirements for the application under test
Convert the conceptual goal into quantitative measurements,
Example: conceptual goal is the SAP SD system should be able to create max orders during peak
SAP SD system should be able to create 1000 POs / hr during peak usage of 200 concurrent users
Classify the SAP critical business process based on the following criteria
Transaction Critical which must be run in order to establish conditions to run other process, example Login, Search
Sales Doc, Create Invoice etc )
Heavy Throughput the business transactions which are frequently accessed by users of SAP system such as VA01,
PA20, ME21N and Payroll run, period end reporting etc..
Dynamic Content : Programs that require high level of interaction with Database which rely dynamic content , such
transactions have a higher probability of failing during periods of heavy load. Example Create PO with multiple line
items
Customized Component : RICEFW development objects/ Z Programs which are customized T codes have higher
risks of failure than the standard programs or T codes as these are written in ABAP and not standard.
Customer Interfaces & Batch jobs which are time sensitive ( start from 4:00AM and ends at 6:00AM)
Session-2Session-2

SAP Performance Testing Process & Methodology
Use the following performance testing methodology & process which should be aligned with the SDLC of the project
that is being implemented at the client place, the below process is proven and self explanatory.
Session-2Session-2
Iterative process

Business Transaction Profile
Once non functional requirements are finalised and signed off from the business/stakeholders, the business
transaction profile looks like as shown below, then you should start mapping the each Business Process to
Automated/loadrunner scripts based on their criticality.
The below table will be achieved based on the interaction with the business users in identification of business
critical transactions and design work load model based on the inputs collected from the business/process owners.
Session-2Session-2
Module
Business
Transactions
Transactions
during normal day
Transactions
during Peak day
Dynamic
Content
Mission
Critical
Include for
Performance test
VA01 800/hr 1000/hr High High Y/N
VL01 500/hr 700/hr Medium High Y/N
VA03 1000/hr 1500/hr Light High Y/N
VF01 500/hr 800/hr Medium Medium Y/N
ME51N 100/hr 150/hr Medium High Y/N
ME21N 75/hr 125/hr High High Y/N
MIGO 100/hr 150/hr High High Y/N
MIRO 150/hr 200/hr Medium High Y/N
Create Expense 1000/hr 1400/hr High High Y/N
Time Sheet log 5000/hr 8000/hr Medium High Y/N
View Payslip 800/hr 5000/hr Light High Y/N
Approve request 200/hr 500/hr Light High Y/N
S & D
MM
HR

Based on my experience in Energy & Utilities/Health Care domain and SAP performance testing carried out for
various clients, following are the critical transactions that should be considered for SAP performance testing for
Sales & Distribution (OTC), FICO, MM, HR(ESS/MSS), BI etc..
SAP Module – Sales & Distribution (SD)
Session-2Session-2
0. Logon to SAP 10. Choose Enter
1. Main screen 11. Call /nVL02n (Change delivery)
2. Call /nVA01 (Create customer order) 12. Choose [F20] (Posts goods issue)
3. First screen 13. Call /nVA05 (List orders)
4. Second screen (with five items) 14. Choose Enter
5. Choose Save 15. Call /nVF01 (Create invoice)
6. Call /nVL01N (Create a delivery) 16. Choose Save
7. First screen 17. Call /nend
8. Choose Save 18. Confirm log off
9. Call /nVA03 (Display customer order)
User interaction steps 2 - 16 are repeated n times (15 user interaction steps --> min. 200 sec. Duration for 1 Iteration).

SAP Module – Financial Accounting (FICO)
Session-2Session-2
0. Logon 11. Select first line
1. Main screen 12. Call Post incoming payments
2. Call Post Document 13. Enter header data
3. Create customer item 14. Choose Process open items
4. Create general ledger account item 15. Select item 5 of the list
5. Choose Post 16. Scroll down to the end
6. Call Display document 17. Select last item
7. Enter previous posted document 18. Deactivate all selected items
8. Double-click first line 19. Choose Post
9. Call Customer line item display 20. Call /n end
10. Enter data and choose Execute 21. Confirm log off
User interaction steps 2 - 19 are repeated n times (15 user interaction steps --> min. 180 sec. Duration Iteration ).

SAP Module – Material Management ( MM)
Session-2Session-2
0. L ogon 10. C hoose E xecute
1. M ain scree n 11. C hoose P ost
2. C all /nM E 51N (C reate purchase
requisition)
12. C all /nM IR O (C re ate invoice), enter
com pan y code
3. E nter data 13. E nter basic data
4. C hoose P ost 14. C hoose P aym ent
5. C all /nM E 21N (C reate purchase order) 15. E nter data
6. E nter data 16. C hoose P ost
7. C hoose P ost 17. C all /nend
8. C all /nM IG O (G oods receipt purchase
order)
18. C onfirm log off
9. E nter data
User interaction steps 2 - 16 are repeated n times (15 user interaction steps --> min. 150 sec.
duration).

SAP Module – HR (ESS Employee Self Service )
Session-2Session-2
User interaction steps 2 - 8 are repeated n times (7 user interaction steps --> min. 120 sec.
duration).
1. Log on to the portal – Welcome page
(includes three iViews)
6. Choose Address
2. Choose Working Time —> Record
Working Time
7. Choose Bank Information
3. Choose Leave Request 8. Choose Benefits and Payment —>
Paycheck Inquiry
4. Choose Leave Request Overview 9. Log off fromportal
5. Choose Personal Information —>
Personal Data

TEST ENVIRONMENT
Dedicated performance testing environment should mimic the production like environment in terms of hardware and
software configuration & Database sizing.
The activities during this stage will involve educating the project team about SAP performance test environment, which
includes identifying and creating a SAP landscape consisting of application servers, Central Instance with Database and
other 3rd party applications ( Like Payroll/Legacy systems etc).
However, for various technical, organizational or economic reasons, it is not always feasible to simulate the full load
expected in subsequent production operation. In addition, it is never really possible to execute the test on hardware
exactly identical to the hardware planned for production.
If the performance test environment is not similar to the production env in terms of hardware sizing , the work load
model should be scaled down linearly to the performance test env/QA environment, for example if the production has 4
app servers and QA env has 1 Application server, accordingly the number of concurrent users/throughput will be
reduced as per the scaled down env.
Important Note: Make sure that the hardware used for the volume test is exclusively reserved for this purpose while the
volume test is run. In-parallel usage of the same hardware or system(s) for other purposes (as, for example, training
system, ) can have disastrous consequences for the volume test and leads to misinterpretation of its results.
Note that SAP system will exchange data with a number of internal and external non-SAP systems, i.e. Interfaces and
Non SAP systems like BACS, PAY Matrix, Billing System, Cyber Source etc.. In order to carry out End to End pperformance
testing, it is essential to connect to the test environments of all the systems identified during testing.
Session-2Session-2

TEST DATA MANAGEMENT
Test data for performance testing is one of the major/critical activity which should be effectively addressed in the early
phase of performance testing with the stakeholders otherwise performance testing during execution will be disastrous.
In many organizations, production data (copy/clone ) is still used for performance testing which may provide an initial
benefit over the alternatives. However, issues with data quality, legal issues from leakage of sensitive data, and cost issues
due to the use of unnecessary data render this option untenable in the long run. Test data management should therefore be
one of the core activities of a successful performance testing projects.
With the right test data and test data management strategy in place, the performance testing/project team can find the
performance issues in the early cycle of SDLC which improves quality, accelerate the release cycles and reduce the cost.
Following key factors should be considered for the test data management strategy..
If the project is new and going live first time, the way to create test data on the PT env is by way of using
applications APIs, or Data Loading tools or using HP Loadrunner tool.
If the application is for upgrade, migration, tech upgrade and in production, the best way of creating data is to take
the production clone and mast the data if its confidential.
Strategy should be in place to reuse the data during the performance test execution this saves much time for the
project schedule, such strategy should have database flash back or data refresh mechanism.
Note that having right size of test data on the performance test environment will have realistic test scenarios
simulated and identify the performance issues in right manner.
Session-2Session-2

We must understand & set the expectation to the stakeholders that which team is going to provide all valid transactional
data, user ids and passwords with proper roles & authorizations for the realistic simulation of user load, for example all HR
user ids can’t have Sales & Distribution Roles, and all SCM user ids may not have HR roles and authorizations. Another
important point we need to discuss with the project team is about the test data setup on the performance test environment
Valid Test data required during performance testing is broadly classified as given below which should be addressed during
the planning phase of performance testing proactively rather reactive during the execution phase..
Master Data : Data That resides in SAP database and is essential to carryout business transactions is called master data.
Basic data created by a limited number of end users and is used in nearly all applications
Remains constant over time, although some master data may need to be updated occasionally
For example, a customer master consists of contracts, invoices and payments for a customer and HR master
consists of employee details as explained in the above examples.
Examples of Master Data:
o Customer Account Number
o Sold To Party
o WBS Cost Element
o Material Number
o Employee Number etc.
Session-2Session-2

Transactional/External Data: The data that is not possible to deduce before the business transaction is carried out is
classified as external data or transactional data. An example of external data is purchase requisition number that the SAP
application/system creates after you create & SAVE a purchase requisition.
Is used for processing business transactions
Is specific for each transaction. For example Purchase Order, would contain details like items, cost and vendor.
User Data:
The data that the users provide/input to he SAP application is called user generated data. This type of data is generally typed
in an editable field. Below are the few of the examples for user generated data as given below.
Session-2Session-2
Example of Transactional/External Data :
o Bank A/c number
o User Name
o GL Account Number
o Purchase Order No etc.
User Data :
o Delivery Date
o Material Price
o Customer Name
o Editable Field etc.

HINT:
Copy Production Data : In case if you plan to copy the production data on to the performance test environment, the
following procedure should be followed in order to be sure that the data copied is of equal size in the test environment.
If we copy data to different environment, for example from Production to QA, then its normal back from production and
then restore in QA.
If we want to copy data to different platform ( say Windows to UNIX) or different DB we need to use "r3load" which is a
tool from SAP to import & export table during installation.
In certain cases the data used should be confidential as a result scrambled data is prepared using 3rd party tool called
DSM ( Data Sync Manager from EPI-USE). This tool is used to scrambled and depersonalize data.
Valid Transactional data can be created using automated tools like HP Loadrunner for the bulk data creation but need to
plan well in advance and after taking consideration of project timelines.
Data Seeding : Often business process consume data for example a shipping request requires a sales order that once
shipped may not be shipped again which will consume the data for each time you run the test iteration. Because of this the
system should be PRE SEEDED with the data consumed by the test execution. To keep testing productivity high there should
be enough data to support the test executions for each iterations before requiring a system REFRESH.
Volume Data : System performance may vary widely with the volume of data. The system under test should have sufficient
data model/transactional data size of the product database as the time of deployment. Its also very important to expand the
DB size to model the system performance with an additional 1 to 2 years of data in the performance test environment for
verifying the actual system performance.
Session-2Session-2

Monitors Setup
We need to understand the application landscape, pen down the list of servers to be monitored during the test execution, you need to
ask the infrastructure team to provide the access to each of the servers to setup the monitors and access to Sitescope.
SAP servers can be monitored either through Loadrunner or manually executing defined transaction in SAP, Monitoring is one of the
most important task in SAP performance testing, note that as a best practice we should not monitor too many counters/parameters in
Loadrunner controller. Too many parameters generate huge amount of data & log files as a result at the end of the execution while
Loadrunner collating the data from all injectors & servers, there is high chance of crash in controller and there by loosing the analysis
data.
Request the BASIS team to provide access to the following Transaction codes which helps the performance testing team to monitor the
transactions during execution..
SAPGUI Monitoring (ST02): Monitors buffer related metrics. SAP transaction ‘ST02’ is executed when running this monitor.
SAPGUI Monitoring (ST03N): Monitors application specific metrics. SAP transaction ‘st03n’ is executed when running this monitor.
SAPGUI Monitoring (ST04): Monitors database related metrics. SAP transaction ‘ST04’ is executed when running this monitor.
SAPGUI Monitoring (ST05): Helps to monitor the SQL Trace view
SAPGUI OS-Monitoring (ST06): Monitors operating system specific metrics. SAP transaction ‘st06’ is executed when running this
monitor.
SAPGUI Monitoring (ST07): Monitors user distribution on the SAP system. SAP transaction ‘ST07’ is executed when running this
monitor.
SM36 To schedule and view the status of batch jobs running in background.
* Monitoring Setup will be discussed more in detail in the session 4
Session-2Session-2

SAPGUI Vuser Foot prints
Note that SAPGUI users are GDI resource intensive, machines running SAPGUI users may be limited in the number of vusers
that can run on injectors machines due to limited GDI resource available on the injectors ( limitation from MS Windows ).
Maximum of 30 ( complex scenarios ) to 50 ( Simple scenarios ) Vusers can be run from a single injector with the machine
configuration of 1GB RAM Dual Core CPU. So in order to run more SAPGU users in performance test execution, we need
more injector machines which will be more cost burden to the project, based on Wipro’s performance engineering
experience across all SAP performance testing projects, we have successfully reduced the cost on procuring more injectors
by using Windows 2003 machines as injectors which will help the team to run more SAPGUI users from single injectors by
opening more terminal sessions and each terminal sessions can have 50 SAPGUI vusers.
The general rule of thumb for SAPGUI load tests is that you can run 50 virtual users on a 1 GB RAM and 1 GHz computer.
It is possible to execute more than 50 users on a computer if you have more power and more RAM, but the increase is not
linear nor can this rule be applied to all operating systems .
Windows Server 2003 seems to handle GUI resources better and it is therefore possible to execute up to 90 or even 100
users on a powerful computer.
*The Diagram in the next slide shows how the performance test lab setup looks typically near the data centre of the SAP
system setup.
Session-2Session-2

Loadrunner Vuser footprint for SAPGUI & SAP Web
Following table below shows the memory footprints for Loadrunner SAPGUI/SAP Web and Web users which helps us to plan for
the number of injectors required for the performance test execution.
Session-3Session-3

PERFORMANCE TEST LAB SETUP
Session-2Session-2

Lab Exercise
Transaction Volumetric Model ( TVM ) as mentioned in the slide 22, derive the excel template
with similar table from different modules in SAPGUI.
Use various T codes to complete the End to End transactions, please refer the slide 23 to
complete the transaction manually. Note that you need to take the help from your lab/CoE to
assist you in completing this as the system should have configured for Master Data to complete
the transactions.
Create another transaction manually for SAP HR system to view the PaySlip in the portal
system.
Login as ESS ( Employee Self Service ) user to create the Time Sheet in the SAP Portal
Login as MSS ( Manager Self Service ) user to approve the Time Sheet in SAP Portal
Session-2Session-2

Session -3
Scripting Best Practice

Session-3Session-3
Following are the topics which will be discussed during this session of Scripting best practice.
Scripting Best Practices
Coding standards
Script enhancement & error handling
Correlation for SAPGUI & SAP Web
Use of SAPGUI functions
Script Debugging and Run Time Settings etc
Lab Exercise

Checklists before Scripting
Before we go to for SAP scripting session, we must keep the below points in mind .
Scripting typically can't start until functional testing has started ( depending on what we are scripting)
As a best practice, we should have the application functionally stable without any major defects ( like P1 & P2 ) which may be
show stopper to proceed with scripting.
Develop your scripts using best coding practices
Component based approach
Don't make code very complex, just because you are expert in coding
Leverage correlation rules both custom built & pre built
Leverage content check rules whenever possible
Comment each business process user step
Use error handling in the scripts
Wrap a transaction around each user step
Use a transaction naming convention and stick to it
Example: ApplicationName_BPName_TransactionNumber_TransactionName
(MyWipro_ESS_001_SubmitTimeSheet)
Include multiple iterations when unit testing scripts
Debug run is final step if scripting ( multiple users, multiple Iterations of a script)
Create and reuse a logging level action
Session-3Session-3

Before we start SAP scripting
Before you start to Script:
√ Only automate transactions that have been successfully manually tested.
√ Ensure all necessary data is at hand before automation and that the documentation is accurate.
√ Optional Screens: Some screens are data dependent – i.e. they are only displayed for certain data values/conditions, we
need to be aware of these to be able to script effectively.
The following guidelines apply to VuGen:
Do not record the logon information within the main Action of your script. For Vugen Use vuser_init (This may be
disregarded if the purpose is to change passwords or other action where logging on is the Business Process under test.)
Ensure that the window is ‘Maximised’.
Use the Transaction Codes instead of Menu Paths.
When entering the SAP Transaction Code (e.g., VA03, MM01) in the command field it should always be prefixed by a ‘/n’
(i.e. /nva03, /nmm01). End each action with “/n” to ensure that each action ends with the SAP Easy Access screen.
Always ensure that the script starts and ends with the same conditions i.e. at the SAP Easy Access screen
Avoid using drop down lists/match codes. Work on fixed values.
Use Parameter/Correlation in test scripts in place of constants where appropriate. Only replace constant values that need
to be parameters.
Remove all unnecessary steps - this may include clicking or selecting fields before inputting data.
Session-3Session-3

ENABLING SCRIPTING ON SAP CLIENT
Setup the SAP Layout before we start scripting : Follow the below 3 steps before we start scripting for SAPGUI
Session-3Session-3
STEP 2 :When the Options window opens select the Scripting tab:
To allow VuGen to interact with the SAP GUI without warning
pop-ups, uncheck the “Notify….” checkboxes as displayed in the
screen-print below
STEP1 : Open up a SAP session and select
“Customizing of local layouts (Alt+F12), the icon on
the far right of the OK Code field. Select “Options”

ENABLING SCRIPTING ON SAP SERVER
Session-3Session-3
STEP 3 : You can enable scripting by setting the profile parameter sapgui/user_scripting to TRUE. The value set using this
procedure will be lost when the system is restarted.
If the administrator edits the application server profile of the SAP System to include sapgui/user_scripting = TRUE, scripting
will be enabled by default when the server is restarted.
Procedure
1. Start transaction RZ11. 2. On the Maintain Profile Parameters screen, enter sapgui/user_scripting.
3. Choose Display. 4. In the Display Profile Parameter Attributes screen, choose Change value.
5. Enter TRUE in the New value field. 6. Choose SAVE Button

IMPORTANT QUICK NOTES
SAP Scripting begins with creating few utility scripts like users creation, resetting password and finally scripting for
the identified business critical scenarios. In order to create users, initially a template user should be defined with the
help from functional expert or consultant.
Note1: In order to create the users the user id should have SAP_NEW access, the users should be created as a replica
of template user as defined by functional expert.
Note2: No test user should be created with SAP_ALL access, a user with SAP_ALL security access goes through least
security check during login.
Note3 : When creating a new user ids ensure on the LOGON DATA TAB the user type is set to SERVICE. This will
ensure us not to change the password on the first instance and saves much time in terms of resetting the password for
the first time user ids created.
Select SAPGUI or SAPWEB protocol in HP Loadrunner for the scripting of SAPGUI or SAPWEB based applications as
available in SAP bundle Vuser protocol license.
Do not record the logon information within the main Action of your script. For Vugen Use vuser_init (This may be
disregarded if the purpose is to change passwords or other action where logging on is the Business Process under test.)
Ensure that the window is ‘Maximised’ while recording the scripts and when entering the SAP Transaction Code (e.g.,
VA03, MM01) in the command field it should always be prefixed by a ‘/n’ (i.e. /nva03, /nmm01). End each action with
“/n” to ensure that each action ends with the SAP Easy Access screen.
Session-3Session-3

Start SAP Scripting
Once you come to scripting phase, invoke HP Loadrunner/VuGen application and select the SAPGUI/SAP Web protocol from the
ERP/CRM template. Make the following selection as shown below, make sure that the SAPGUI client is installed on VuGen &
Injectors boxes.
Session-3Session-3

Start SAP Scripting
Once you come to scripting phase, now its time to select the Loadrunner SAP Bundle protocol ( SAPG UI or SAPWEB depending
upon how the business scenarios are accessed by the users.
The below script snippet shows the example of SAPGUI login to the SAP application after successfully replaying , please note
that password field will have **** instead of actual password which is replaced by the actual password otherwise the script will
not replay.
Session-3Session-3
ExpsExps
ExpsExps
ExpsExps

Coding Standards
Once the script is developed and run successfully for intended business process, make sure that your scripts has the coding
standards for any auditing/experts verification & sign off
SCRIPT HEADER
The following format should be used for the header:
/* -------------------------------------------------------------------------------
Script Title : MyExpense_001_ESS_CreateExpesne
Script Description : This script creates the expense for an employee of the ESS user
Created by : Suryakanth Kelmani
Created Date : 30th Jan 2014
Changed by : SK
Changed Date : 12th Feb 2014
Changed reason : Switch to MSS test users for new roles.
------------------------------------------------------------------------------- */
All major changes to the script should be recorded in the Header. It should include, who made the change, when and why the
change was made, as in the above example:
SCRIPT NAMING CONVENTION
Scripts should be named with the format: {Project}_{Business_Process_Number}_{Business_Process_Name}
Where: {Project} is the Project or Application name (format 6 characters with first letter capitalized)
{Business_Process_Number} is the Business Process number (format 3 numbers e.g. 001, 002 and 003) as shown in the
example below..
MyExpense_003_ESS_CreateExpesne
Session-3Session-3

Coding Standards
TRANSACTION NAMING CONVENTION
Transactions should be named with the format: {ProjectName}_{xxx}_BP_Name_{yyy}_{TransactionName}
Where : {ProjectName} is the Project or Application name.
{xxx} is the Business Process (or script) number (with a leading zero as needed).
BP _Name is business process name and {yyy} is the sequence number of the transaction within the script.
{TransactionName} is the action being analysed e.g. login.
Note : Please remove the transaction timers ( THINK TIMES ) if you have any and place them outside the transaction
names
Session-3Session-3
ExpsExps
ExpsExps

Data Parameters
Need for Parameterisation :
Data-related problems may occur when you replay a execute script for multiple users and multiple iterations, to resolve these
issues we need to parameterise the data, the most common data related problems are as given below and are going to be
discussed in detail
•Date or Time constraints
•Unique Data
Types of Parameters : While creating a parameter, we need to specify the source for the parameter data which can be
specified from Master Data, Internal Data Parameter and User Defined Data Parameter.
1. Master Data Parameter: Data is stored in a file that the script accesses during execution, we can retrieve data from an
existing file or can create a new file or can import from a database. Note that Master data types are
FILE : Replaces the parameter with a value stored in a file
TABLE : Replaces the parameter with a value stored in a Table
2. Internal Data Parameter : Data that a script generates automatically, internal data types are..
DATE/TIME: Replaces the parameter with a value of current date/time of the system
RANDOM NUMBER : Replaces the parameter with a value of Random Number
UNIQUE NUMBER : Replaces the parameter with a value of UNIQUE number
ITERATION NUMBER : Replaces the parameter with a the current iteration number
3. External Data Parameter : Data is generated by using a function from an external DLL, the parameter in the script is
replaced with the value returned from the function placed in an external DLL, we can use for example lr_load_dll
(“C:SRKdata.dll”) to call any DLLs in your scripts.
Session-3Session-3
•Data Dependency
•Data Caching

Data Parameters
Date or Time Constraints :
A script which is recorded a week or few days back before the test run could cause errors in the test execution. The date
recorded in the script is a past date but the application required current or future date to the script successfully, in this case we
need to change date to current or future date to resolve this issue. The sample code is given below
Session-3Session-3
Delivery date works
only for the current
date or future date
lr_save_datetime("Tomorrow is %B %d %Y", DATE_NOW + ONE_DAY, “TomorrowDate");
lr_output_message(lr_eval_string("{TomorrowDate}"));
sapgui_set_text("Req.deliv.date", "{TomorrowDate}", "usr/ctxtRV45A-KEYDAT“, BEGIN_OPTIONAL,
"AdditionalInfo=sapgui1034",
END_OPTIONAL);

Data Parameters
Unique Data
The application may have a filed that requires a unique data value, when multiple users use the same data set , an error occurs
during the test execution. Example, the test assigns a user name to login to the application and prevents two users from using
the same user name to login to the system. We can parameterise the text filed to get a unique value each time a test is run.
Session-3Session-3
User id need to be
unique for each users

Data Parameters
Data Dependency
The application may have a filed that depends on the value of another filed co exist to each other, for example as shown in the
below screen shot, each user id has the corresponding password , we can parameterise the dependent filed together to avoid
possible errors resulting from data dependency.
Session-3Session-3
User id is dependent on
the password

Data Parameters
Data Caching
Data caching may not cause a script to fail, but can produce misleading results. For example, we test an application for response
time from the server. When the first virtual user makes a request, the data is retrieved from the database in a specific amount
of time. This data is stored in data cache and takes lesser time for retrieved than for the first user. The difference in the results
of both the users renders the functionality of the script.
Session-3Session-3
User-1 User-2 User-3
User-2User-1
DATABASE
SAP
APPLICATION
SERVER
3.8 Sec
1.7 Sec
1.7 Sec
3.8 Sec
3.5 Sec
3.7 Sec
User-3
Script which is parameterised, the data is not cached due to different data and average
response time is 3.7 Sec.
Script which is not parameterised, the data is cached due to same hardcoded data and average
response time is 2.4 Sec.

Capture Dynamic Values
HOW SAPGUI Correlation works:
Correlation of dynamic values in a script involves the process of capturing the output generated by a system as an
input for another system, this helps to run the scripts without any issues. We need to correlate to
•Correlate dynamic values in different parts of the code
•Capture & reuse the dynamic value to run the script without any interruption
•To use unique data in the scripts
The Benefits of using correlation in our script enables to handle issues arising from data dependency, to handle
dynamic data and to accommodate unique data records .
Session-3Session-3
Create Purchase Requisition
SAP Application
Purchase Requisition Num: 100786
Edit Purchase Requisition
SAP Application
Purchase Requisition Num: 100786
OUT - 100786 IN - 100786
Parameter= 100786
in your script

Capture Dynamic Values
The sample script for capturing dynamic value is shown using Loadrunner function to get the text of status bar as
below
sapgui_status_bar_get_text("paramStatusBarText", LAST);
sapgui_status_bar_get_param("1","Doc_Num");
Session-3Session-3
Document number to be
captured in the script
Use the function to
capture the value and
save it in a parameter

Correlation in SAP WEB
SAP web correlation is similar to any web applications, the most important correlation that is required for SAP web application ( be it be
SAP SRM, CRM, ESS/MSS modules ) is given below ..
SAP_JSESSION_ID
SAP_ EXT_SID_ID
SAP_ WD_ TIME_STAMP
SAP _CONTEXT_ID
SAP_WD_SECURE_ID
SAP_DSM_GUID
We can quickly add the above correlation manually wherever appropriate in Loadrunner scripts, this helps us to reduce the
time in identifying correlation quickly.
//correlating the Jsession for SAP SRM or SAP CRM
//Webdynpro/dispatcher/sap.com/tc~kmc~bc.uwl.ui~wd_ui/UWL;jsessionid=(J2EE438770300)ID1093350754DB6d3b34cc36c5
2c738368ba087e00743c00e16cadEnd“
web_reg_save_param(“P_jSessionID",
"LB=webdynpro/dispatcher/sap.com/tc~kmc~bc.uwl.ui~wd_ui/UWL;jsessionid=",
"RB="",
LAST);
-----------------------------------------------------OR--------------------------
//jsessionid=(J2EE29199700)ID0328432251DB576b2498baa897ddc63d26961690441b7a5f44a0End"
web_reg_save_param(“P_ SAP_Jsessionid1",
"LB=;(",
"RB=&",
LAST);
Session-3Session-3
web_reg_save_param(“P_SAP_Jsessionid2",
"LB=)",
"RB=End",
LAST);

Correlation in SAPWEB
//correlating the SAP_ EXT_SID_ID
//name="sap-ext-sid" value="fK4qxjVJPG3OBy_pCnIKKQ--fdvZw3_mBW8ve_DxKg9Mkg-- ">
web_reg_save_param(“P_sap_ext_sid_id",
"LB= sap-ext-sid" value=" ",
"RB=”",
LAST);
// Correlating SAP_ WD_ TIME_STAMP
// <input type="hidden" name="sap-wd-tstamp" value=" 1322068237859 ">
web_reg_save_param(“P_sap_wd_timestamp",
"LB=sap-wd-tstamp" value="",
"RB="",
LAST);
// Correlating SAP _CONTEXT_ID
//?sap-contextid= SID%3aANON%3asap6008q_QS1_02%3aaolL3aqbyfJiLKLaDcLqUTToeHG27kFVndwys W2V-NEW&a
web_reg_save_param(“P_SapContextid",
"LB=?sap-contextid=",
"RB=&",
LAST);
Session-3Session-3

Correlation in SAPWEB
// Correlate uwlSessionID
// 1322068237858@uwl@2599 is replaced with Parameter {uwlSessionId}
web_reg_save_param( “P_uwlSessionId",
"LB= value="",
"RB="", "Ord=12",
"Search=Body", LAST );
// Correlate Sapsecureid
//name="sap-wd-secure-id“ value="839BC65D548534D2F3698D8F189C993B"
web_reg_save_param("Sapsecureid",
"LB=name="sap-wd-secure-id" value="",
"RB="",
LAST);
Note that some of the correlated parameter get the response in HTML/URL, please use the Loadrunner function to
convert the content appropriately using
WEB_CONVERT_PARAM (“ParamterName”, “SourceEncoding=HTML”, TargetEncoding=URL”, LAST);
Session-3Session-3

Error Handling in your Script
Your scripts should be more robust in terms of error handling and reusability, we can enhance the automated scripts by adding
Loadrunner functions manually ( apart from Correlation & Data Parameters which we discussed in earlier slides ), we should
handle the optional SAP Windows or SAP Objects, retrieve text from object etc. Enhancing the scripts will enable us to
View Customised Messages
Verify during execution of script that an Object exists
Handle an optional window in SAP
Retrieve the text of an Object
Upload of an excel/Doc/PDF file into the application ( ex. Invoice file, Order file )
The following scripting snippets makes you to quickly implement the logic during performance testing projects across SAPGUI
and SAP Web applications, this will save your time by quickly implementing in your scripts.
Many of the enhancements in SAP scripts can be implemented by SAPGUI functions, before we discuss about the
enhancement, we need to understand the CONTROL ID of the SAP Objects.
CONTORL ID : Loadrunner script in VuGen identifies an object by a unique number as the CONTROL ID of the SAP Object. We
must use these CONTROL IDs of Objects to add new steps in the script. Loadrunner captures the CONTORL ID for each object in
the active screen shot (Similar to QTPs active screen technology ) while recording . You can copy the control ID of an object by
right clicking on the Object in the screen shot and play around with the available functions.
Session-3Session-3

Error Handling in your Script
Overview of Message Functions:
You can use message functions in the scripts to send the logs, Error and output messages to the o/p and log files.
We can use the following message functions in our scripts
lr_log_message ( ); which sends an output message directly to a log file
lr_error_message ( ); which sends an error message to both the output window in red and the log files
lr_output_message ( ); which send a message to both the output and the log files
Session-3Session-3

Object/Dynamic Windows Handling in your Script
The following example uses sapgui_is_object_available to see if a grid is visible. If not, it clicks the expand button that displays
it. After ensuring that the grid is visible the script can work with it.
sapgui_set_ok_code("/nME51N", LAST );
sapgui_send_vkey(ENTER, LAST );
// Store Grid ID in "ContainerObjectID" to make code more readable
lr_save_string("usr/subSUB0:SAPLMEGUI:0016/subSUB2:SAPLMEVIEWS:1100/subSUB2:SAPLMEVIEWS:1200/subSUB1:SAPLME
GUI:3212/cntlGRIDCONTROL/shellcont/shell", "ContainerObjectID");
// Store expand button ID in "ButtonID"
lr_save_string( "usr/subSUB0:SAPLMEGUI:0016/subSUB2:SAPLMEVIEWS:1100/subSUB1:SAPLMEVIEWS:4001/btnDYN_4000-
BUTTON", "ButtonID");
// If the grid is not available, click the expand button
if ( !sapgui_is_object_available ("{ContainerObjectID}", LAST)) sapgui_call_method("{ButtonID}",
"press",
LAST );
// It is now certain that the grid is available.
Session-3Session-3

Upload file in your SAP Script
The below code snippet shows how to use the below code to upload file ( Excel/PDF/Doc etc ) in SAP business
scenarios.
sapgui_set_text("Order_FILEPATH",
"D:SRKorder_no_1.xlsx", // File Path
ctxtOrder_FILEPATH, // Control ID
BEGIN_OPTIONAL,
"AdditionalInfo=sapgui954",
END_OPTIONAL);
Add the below control id code in “ lr_string.h” of the script
const char* ctxtOrder_FILEPATH =
"usr/ ctxtOrder_FILEPATH ";
Session-3Session-3

Verification Point in SAPGUI Script
At least 1 verification should be added to the script to let us know if the script was successful or not. This helps the us to
identify if the transaction is working properly. If there are no successful updates for a transaction that should be updating
documents, then investigation of the transaction may be required.
The example below captures the status bar text that shows that the meter reading results were entered successfully:
This code example also sets a value in a parameter that will be used to tell the script to output the successful account. A think
time may be necessary as sometimes Performance Center may report an end transaction as failed as insufficient time has
passed.
Session-3Session-3

Verification Point in SAP Web Script
Similarly for SAP Web protocol as shown in the below code snippet..
Session-3Session-3

Recovery from Errors in SAP Scripts
Recovery from errors., is important point need to be noted as we can instruct the script to exit the iteration and start the next
iteration on error. We need to include the below code at the top of first ACTION to select the window and enter the neutral
transaction ns0000 . The instructions in the script will override the runtime settings of continue on error (which don’t make
sense in a long script with dependencies as we know that nearly all the subsequent steps will fail).
Include the following code snippet at the first line of the first ACTION as shown below
// Start of recovery scenario
// End of recovery scenario
Include the following line of code in the last line of the last action in the script.
lr_continue_on_Error(0);
Session-3Session-3

VuGen replay Common Practice
Following are the common practice for Run Time Settings in VuGen for replaying the scripts to debug. Make sure that once all
the required scripts are ready for the performance test execution, make sure these scripts go through peer review and then for
the final review by the business to verify the scripts are doing the intended business process.
Common Practice to replay the scripts in VuGen:
Session-3Session-3
Use Standard Log & Extended Log to find the
problematic steps and control IDs.
Ignore Think Time during the replay in VuGen
Ignore pacing
Use “SHOW SAP client during replay ” and “Take
Active screen shots during replay” which will help
us to debug errors

Lab Exercise
Setup the performance test lab with SAPGUI client installed on injectos.
Create & run one script ( any transaction i.e VA01 ) without setting the “SAPGUI_user
scripting” enabled using RZ11 Transaction code and see the difference.
Create & run the same script (i.e VA01 ) with setting the “SAPGUI_user scripting” enabled using
RZ11 Transaction code and see the difference.
Use various Monitoring T codes to get familiar with the monitoring the SAP system.
Create one End to End script either in SAPGUI or SAPWEB and implement the coding standard
as mentioned in the above slides.
Make use of functions to capture the dynamic values in SAPGUI and SAPWEB scripts.
Session-3Session-3

Session -4
Execution & Monitoring

Session-4Session-4
Following are the topics which will be discussed during this session of SAP Performance Test Execution Best
Practices
Performance test execution readiness
Smoke test of Individual Scripts and Batch jobs/Reports and Interfaces
Scenarios calibration & run time settings
Light, Medium and Heavy load approach
Peak Load, Stress and Scalability test strategy
Monitoring setup verification & Log enable
Lab Exercise – scenarios executions

The objective of this session is to make sure that the resource will be able to define
Run Time Settings for SAPGUI and SAPWEB
Scenarios setup.
Monitoring setup and Checklists
How to run more SAPGUI users on limited number of Injectors
Session-4Session-4

Quick Notes on the Execution before we start further.
The objective of this session is to make sure that the resource will be able to define
Make sure that all the test scripts are ready and signed off by the business, make sure you have enough test
data for the execution, Environment is stable and Monitors are setup & working.
Execution should not start until at least one round of functional testing has been completed without any major
functional defects which is a show stopper for performance testing.
Interactively monitor your scenarios during the execution and taking notes for the performance issues and
system behaviour with regard to the resource utilisation, spikes in transaction response time, network band
utilisation etc.
Make sure that you include the stakeholders (Project Team, BASIS, ABAP, DB and Functional team etc. ) as
explained in earlier session you should have shared the execution & the resource plan to support this activity
well before the scripting phase.
Ensure that the Monitoring tools & Diagnostic setup is in place and all working with the required access to the
servers verified along with the counters ( CPU, Memory. Disk I/O etc.)
Note that the execution should continue until we have at least two CONSECUTIVE successful runs.
Execution & Analysis is an ITERATIVE process that runs scenarios, analyse results and debug/fix the
performance issues if any.
Session-4Session-4

Common Practice in Controller scenarios & Run Time Setup.
Create “Shell” scenario for each project that contains all of the monitoring profiles and load generators for the
project.
Take notes during execution in the “Execution Notes”
Make sure that you validate Logging levels are appropriate and properly setup for each script in the scenario.
No Standard & Extended log levels setup is recommended unless its required for debugging purpose.
Use appropriate “Pacing” and Random “Think Time” in the run time settings for the execution.
Don’t enable “SHOW SAP client during replay ” and “Take Active screen shots during replay” which will have
over head in the logs and disk size.
Set up the required Vusers in scenario to Ramp Up Vusers one by one with a gap of 2 to 3 sec and reach steady
state to run for 1 hour peak before all the users start gradually ramping down to match the performance
requirements defined in the plan.
Don’t overwrite the results after debug runs are complete.
Ensure Vuser quota is appropriate to meet your project requirements.
Session-4Session-4

To Run more SAPGUI Vusers on Injectors.
Injector machines running SAPGUI Vusers may be limited in the number of Vusers that can run, due to the
graphic resources available on that machine. To increase the number of Vusers, open Terminal Server sessions
on the load generator machine and relate each terminal server session to the load generator. This means a
Terminal Server must me running on the load generator.
Windows Server 2003 and 2008 Standard Edition/Enterprise Edition SP2 32-bit both come with Terminal Server,
please use the injectors with the above OS to activate terminal sessions, note that each machine will have 3
terminal sessions available with no cost from Microsoft, you can open three sessions one each Injector and can
run Max of 50 SAPGUI users ( totally 150 SAPGUI users on Single Injector ) which saves cost for procuring
additional 2 Injectors .
Follow the below instructions to setup Terminal Sessions for each of the injectors you are going to use in your
test execution.
Session-4Session-4
Step 1. On each Injector machine, go to START Programs-->
Loadrunner Advanced Setting Agent Configuration and
Enable the Checkbox for “Enable Terminal Services” as shown
below.

To Run more SAPGUI Vusers on Injectors Contd….
Session-4Session-4
Step 2. From any Injector that has the Terminal Services Client installed, create at least two connections
to the Load Generator, if the load generator has Terminal Services Client installed, then create a
connection to itself. Then start up the LR Agent Process in each Terminal Server Session.
Step 3 : Once the sessions are created, the terminal sessions in Controller for the injectors look as
shown in the next slide,
From the Controller, define your load generators using the following conventions which is preferred
<Machine _Name or IP>:1

To Run more SAPGUI Vusers on Injectors Contd….
Session-4Session-4

Windows Monitors Setup
Make sure that once the system resource monitors on application servers, DB servers are setup & configured as
expected. This may include system resource monitors for Windows and Unix machines.
Using performance testing tools like HP Loadrunner/Neoload/Performance Center enables us to use Windows
operating system performance counters to trace behavior of system under test.
Windows system resource monitor can be configured in Loadrunner controller/Sitescope easily if you have READ
access rights to the server which you want to monitor.
As a best practice caution should be taken not monitor too many parameters using Loadrunner controller as monitoring
too many parameters generate huge amount of data & log files. As a result at the end of the run/execution of test while
loadrunner is collating data from all injectors and server boxes there are high chances of controller crash or incomplete
collation of results.
Below are the objects and counters to use in the windows resource monitors. Counters of each objects are given next
slides.
Processor
Memory
Disk I/O
Network
Session-4Session-4

Windows Monitors Setup Cont..
Processor : These processor utilization measurements allow us to determine which applications are responsible for CPU
consumption. The below table shows the Object name and each counters needs to be monitored with description.
Session-4Session-4
Object Counter Description
% Processor Time Counter
Indicates the percentage of elapsed time
that the processor
spends to execute a non-idle thread
% Privileged Time Counter
Indicates the percentage of elapsed time
that the process
threads spent executing code in privileged
mode
% Interrupt Time Counter
Indicates the time the processor spends
receiving and servicing
hardware interrupts during sample Intervals
Processor Queue Length
Counter
Indicates the number of threads in the
processor queue
Processor Queue Length
Counter
Indicates the number of threads in the
processor
queue
System Up Time Counter
Indicates the indicator of overall system
availability
Processor

Memory : Windows maintains physical and virtual memory. A shortage of RAM is often evident indirectly as a disk
performance problem, when excessive paging to disk consumes too much of the available disk bandwidth.
Consequently, paging rates to disk are an important memory performance indicator. On 32-bit systems, virtual memory
is limited to 4 GB divided between 2 GB private area and 2 GB shared area. Having large amounts of physical memory
does not prevent from shortage of virtual memory and may lead to fatal crashes in case of memory leaks when
application does not release allocated memory after usage.
Session-4Session-4
Available Bytes Counter
Indicates the amount of physical memory
available to processes running on the
computer
Pages/sec Counter
Indicates the rate at which pages are read
from or written to disk to resolve hard page
faults
Paged Pool Bytes
Counter
Indicates memory leaks
Page Reads/sec Counter
Indicates that the working set of the process
is too large for the physical memory and that
it is paging to disk
Memory

DISK I/O : Through the I/O Manager stack, Windows maintains physical and logical disk operations. A logical disk
represents a single file system with a unique drive letter. A physical disk is the internal representation of specific
storage device - be it SCSI or RAID or SATA or other technology. When using complex storage systems such as array
controllers or RAID, the underlying physical disk hardware characteristics are not directly visible to the operating
system.
These characteristics - namely, the number of disks, the speed of the disks, their seek time, rotational speed, and bit
density as well as some optimization features such as on-board memory buffers - can have a major impact on
performance. Advance features like memory buffers and command-queueing can boost the performance by 25–50%
Session-4Session-4
Avg. Disk secs/transfer
Counter
Indicates physical disk potential bottleneck
% Idle Time Counter Indicates physical disk utilization
Avg. Disk Queue Length
Counter
Indicates, although in conjunction with other
counters, a potential bottleneck of a disk
Free Megabytes Counter Indicates logical disk space usage
Disk Transfers/sec
Counter
Indicates whether physical disk is a potential
bottleneck
DISK I/O

NETWORK : Network traffic in Windows is measured at the lowest level hardware interface and at higher levels of
network protocol, such as TCP/IP. Network interface statistics are gathered by software embedded in the network
interface driver layer. This software counts the number of packets that are sent and received. Multiple instances of the
Network Interface object are generated, one for every network interface chip or card that is installed.
Session-4Session-4
Bytes Total/sec Counter This indicates total throughput
Server Bytes Total/sec
This indicates overall server utilization in
terms of
Connections Established
Counter
This indicates TCP protocol connection
success rate network
Segments Received/sec
Counter
This indicates number of TCP data segments
received
% Interrupt Time
This indicates the time the processor spends
on hardware devices interrupts, such as
network card
Network I/O

From the above slides we can drill down to the following counters/parameters which should be configured for OS
resource monitoring on the application servers, DB servers to analyse the resource utlisation.
Session-4Session-4
S.No Server Paramter/Counters to Monitor
Import tnsnames.ora file in controller to connect to Oracle
database. DBWR transaction table writes (V$SYSSTAT 1) ,physical
reads (V$SYSSTAT 1) , physical reads direct (V$SYSSTAT 1) , physical
writes (V$SYSSTAT 1) , physical writes direct (V$SYSSTAT 1)
3 Oracle DB Server
4 Unix Server
Average load (Unix Kernel Statistics)
CPU Utilization (Unix Kernel Statistics)
Disk Traffic(Unix Kernel Statistics)
Paging Rate (Unix Kernal Statistics)
% Disk Time, % Processor Time, File Data Operations/Sec,
Processor Queue Length.
Interrupts/Sec ( Memory), Page Falults/Sec(Memory), Pages/Sec
(Memory)
2 SQL DB Server
% Disk Time, % Processor Time, Pages/Sec (Memory),
Processor Queue Length.
Application Server1

UNIX Resource Monitor
UNIX monitor gives the system resource parameters of Unix server box. In order to run UNIX monitor successfully on
Loadrunner controller, you need to run rstatd daemon service on Unix server box, you can ask database admin team to
set this service running, or else you can ask him to carry out the following steps as shown below..
To configure the rstatd daemon:
1 Run the command: su root
2 Go to /etc/inetd.conf and look for the rstatd row
(it begins with the word rstatd). If it is commented out (with a #), remove the comment directive, and save the file.
3 From the command line, run:
Kill -1 inet_pid
Where inet_pid is the pid of the inetd process. This instructs the inetd to rescan the /etc/inetd.conf file and register all
daemons which are uncommented, including the rstatd daemon.
4 Run rup again.
If the command still does not indicate that the rstatd daemon is configured, contact your system administrator.
PS: You can configure the remaining monitors like Oracle Database and Windows resource monitor just by adding their
respective IP addresses.
Session-4Session-4

Execution Approach
Once the scenarios have been designed in HP Performance centre/ LR Controller with required runtime
settings, we now need to execute the scenarios in following manner to find any loose end of the system,
which is also called as SMOKE testing.
The Test execution should be carried out in the following steps before you reach the actual test cycles like
Peak Load, Stress Test and Soak Test etc. This approach helps the team to analyse and Isolate the
performance bottleneck at the earlier phase of performance execution cycle.
Light Load: Design the scenarios in controller with few users to verify the functionality of SAP application
works without any show stoppers issues. This make sure that the slow transactions can be identified at the
early stage proactively.
Moderate Load: Second step is to run a moderate load ( say around 20-25% of actual load, this kind of
test will help to flush out major system issues that don’t affect the functionality of SAP system
Heavy Load: Finally the last step to run a full-scale load test and this should be the entry criteria for
conducting PEAK LOAD, STRESS TEST and SOAK TEST cycles identified for the performance test.
Note that typically two activities proceed parallel during this phase – Analysing TRANSACTION
RESPOSNE TIME and WHITE-BOX performance metrics.
Session-4Session-4

Execution Approach Contd..
Note that as discussed in our planning approach and methodology in earlier sessions or slides, the scenarios should be
tested in isolation to verify the performance of the components so that the performance issues can be analysed &fixed
for each components. This saves much effort during the peak load test when online users, batch jobs, interfaces and
reports tested together.
Execute Online Users in SILO
Execute Batch Jobs in ISOLATION
Execute REPORTS/INTERFACES/REPORT Extraction alone to verify the performance
Finally the PEAK load test during this you should include all the above E2E scenarios and
execute together to mimic the real world users profile behaviour.
Session-4Session-4

BATCH JOBS EXECUTION IN SAP
Objective
Verify the batch jobs are performing as per the criteria defined in the NFR on the test environment as
scheduled in the production setup to ensure that the critical batch jobs process the required volumes within
the defined time window.
Challenges may face
Work Load Scheduler setup on the test env but no sub sets of the system available and batch jobs are
currently tested with some of the systems disconnected.
No performance metrics available for each batch jobs in the systems ( getting only start, end time and status
but no CPU utilization)
Pre-requisite
Identify the batch jobs which are critical & high volumes.
Deploy production batch jobs setup on to the test environment using Tivoli/SM7/M Controller etc.
End to End connectivity setup for flow.
Input files ( e.g. Customers/transactions ) required to trigger the batch jobs.
Configure performance monitoring tool to get the performance metrics for each jobs
Approach
Capture the baseline performance data for the batch jobs on the production environment.
Trigger & capture the performance data for the batch jobs on the test environment.
Configure monitoring tool on the test environment to capture the performance metrics.
Generate performance report
Compare the production batch jobs baseline report with the jobs run on the test environment
Take the help from functional team to setup and trigger the batch jobs as some times you may not be given
the permission to trigger the batch jobs.
Session-4Session-4

BATCH JOBS EXECUTION IN SAP
Session-4Session-4
Input Data
Workload
Scheduler
Controller M
SAP
System
Statements
Output
Performance Monitoring Tool
Batch Jobs Name: Payroll Run
Batch ID & App ID: Payroll_1045
Start Time: 00:00:45
End Time : 00:40:05
CPU Utilization: 3%
Legacy
System
Virtualised
Systems
OMS
System
Payroll
System

PEAK LOAD TEST STRATEGY
Session-4Session-4
A comprehensive strategy should be devised to ensure maximum coverage of applications across the
entire landscape. Test scenarios should include online users, Batch Jobs, Interfaces and Reports as a
background noise during the peak load scenario.
SAP vusers will be ramped up gradually till it reach the required peak load and scheduled to run steadily
for a duration of one hour before all the users start ramping down, during this period the performance
metrics on SAP servers will be monitored for any performance issues. Make sure that you have
background noise during the steady state run as stated above.
Peak Load - Steady State
ResponseTime
SAP Vusers covering E2E scenarios+ Background
noise of Batch Jobs/Interfaces/Reports etc.
Acceptable Response Time SLA

SCALABILTY TEST STRATEGY
Session-4Session-4
Scalability testing is to determine SAP system behavior by increasing the vusers load with a particular
scaling ratio, this test should be carried out after successful completion of peak load test where all
performance hotspots/bottlenecks have been fixed on the pre prod environment.
The above approach will help the team on determining the SAP system performance behavior before
reaching the stress point, this is done with a continuous iterative testing...
By increasing SAP online user load
By Increasing number of records/data volumes to verify the scheduled batch jobs/interfaces run
within the time window
At each level performance metrics will be monitored on the SAP servers to verify the system
resources are within the stress point threshold
ResponseTime
SAP users covering E2E scenarios + Batch Jobs/Reports
Acceptable Response Time SLA
Max Acceptable threshold - stress point
Scalability test - Steady State

SCALABILTY TEST STRATEGY contd..
Session-4Session-4
This test helps us to identify the SAP application infrastructure is scalable and verify at what point the
application starts degrading without performance issues in terms of end user response time and
resource utilization.

SCALABILTY TEST STRATEGY contd..
Session-4Session-4
i
Execution Phase
Execute the test the scenario
by increasing the load as per the
scaling limit.
Execute the batch jobs with
increased volumes
Collect the performance Data
Analyse the data
Problem investigation
Update the test document
Is scalability
limit reached ?
YES
NO
i
Increase the number of virtual
users as per the scaling factor.
Increase the number of
records/volumes for the batch job
processing
Update the test document
i
Completion Phase
Scalability test
completion report
generation
Update the test
document,
Observations &
Recommendation Report
with #user load the SAP
system can scale up with
max stress point reached.
SAP Project Team Interaction

TEAMS DEPENDENCIES & SUPPORT REQUIRED
Its very important that the technical staff and other stakeholders of the project with administration/tuning experience
in SAP ECC, Database and Application server is extremely valuable in the analysis & tuning process. Individuals with DB
Admin, Server Admin, Network Team, ABAP team, Functional and BASIS expertise are required to support the
activities.
Session-4Session-4
SAP
PERFORMANCE
TESTING
&
TUNING
BASIS
Team
Network
Admin
Server
Admin
Infrastructure
Team
Functional
Team
Performanc
e Testing
Team
ABAP Team

Lab Exercise
Creating the scenario & calibration to mimic the real world profile as mentioned in the work
load module derived from session 2 exercise.
Make use of best practice for execution and run time settings
Use the checklist to verify the test environment readiness for execution and check all the
configured monitors profiles are working as expected.
Check for the batch jobs execution in the SAP system using SM47 code.
Session-4Session-4

Session -5
Analysis & Tuning
Best Practice

Session-5Session-5
Following are the topics which will be discussed during this session.
Analysis Best Practices
Performance Analysis & Tuning process
SAP Performance Monitors & CCMS
Performance Stats analysis
Prepare interim test report for each tests
Provide recommendations & Suggestions for tuning

The objective of this session is to provide the analysis skills and at the end of the session the resource
will be able to
Understand the analysis approach
Understand the support required from the various teams ( BASIS/ ABAP/ FUNCTIONAL Team and
Other stakeholders.
Auto correlate the results
Stats from different systems and their metrics & threshold measurements etc.
What should go into reporting ( Summary, Observations, Recommendations etc.)
Session-5Session-5

Performance Analysis & Tuning Approach
Session-5Session-5
After the performance test execution of each cycles, performance testing team should provide an interim
performance test report highlighting observations & recommendations to project stakeholders to take
further action on fixing any performance bottlenecks by carrying out root cause analysis (RCA), once the
defect is fixed, performance testing team will rerun the test to verify the fix.
The important process/activities that will be carried during the analysis are..
Monitor and gather performance test results / logs for the analysis
Analysis of performance test results to identify the performance bottlenecks
Defect reporting and recommendations in fixing the issues
Project team ( ABAP, Basis or infrastructure team ) will provide the fix on the environment to
address the defect
Performance test team will rerun the test to verify the performance bottleneck fix.
As mentioned in my earlier slides, the team involved in performance issues fix are
Basis Team, ABAP Team, Infrastructure team
Process owner/functional team for any configuration required to fix the issue
Performance test team to verify the fix by rerunning the scenario
SAP Project team

Improving Performance
Session-5Session-5
Performance may be defined by the following KPIs (key performance indicators) according to which performance is
measured:
Response time – Speed with which the system reacts to a request or other input
Throughput – Number of successful transactions per time period, also known as the rate of work
Dialogue Steps/Sec
Resource utlisation within the threshold
After unsatisfactory performance is identified as a problem due to high response time or low throughput, it is necessary
to determine the cause and the actions to be taken.
Dealing with a Specific User Complaint ?
Sometimes particular using may be facing performance issues as many of other users may not have the issues, in this
case follow the following steps to do the RCA.
• ...
• Identify the specific scenario.
– Check if the performance issue applies to the entire organization or only to specific user groups or roles.
• Check the hardware.
– Is the user using a standard client machine?
• Gather the following information like – Number of HTTP round trips, CPU usage ( client & server), thread contention –
for server only, DB usage ( DB Locks, Full scans, number of rollbacks ) and Memory usage.

Improving Performance
Session-5Session-5
Actions to improve the performance of the system consists of any of the following components
in the SAP landscape to isolate the performance issues.
Tuning the system (requires understanding of the configurable parameters)
Tuning the application
Distributing load more evenly ( dispatchers and work processes )
Optimizing code (ABAP code for Z programs )
Adding hardware (sizing)
Before performance can be optimized you need to identify problematic areas. Performance
involves a combination of many different aspects, but, in general, each performance problem
can be categorized as belonging to one of following areas:
Server
Network
Client

Analyzing Performance Issues
Session-5Session-5
Following are the high level steps for analysing the performance issues.
Step 1. First identify the software components involved in the business scenario and the
interaction between them.
Step 2. Identify the appropriate possibilities for monitoring the performance of the
components.
Monitor the important metrics of every system involved in the scenario, for example:
Application server
Database
LDAP
Back-end systems

Analyzing Performance Issues
Session-5Session-5
Monitor all processes:
Dispatcher node
Server nodes
Database
Enqueue server
Message server
Step 3. Reproduce the problem.
Step 4. Conduct measurements and analyze the results.
Important metrics to gather for each process:
CPU consumption
Network load
Memory consumption
Paging
Disk IO
I am going to explain more in my next slides about monitoring techniques and T codes to be used for
monitoring purpose.

SAP Top Transaction Codes for Performance Analysis & Tuning
Session-5Session-5
For performance tuning of SAP system the following standard tools/ SAP T Codes are used most of the
time for the performance analysis & tuning of SAP ECC system/Netweaver applications, they are
mentioned as below. Its good if you learn and understand what these SAP T codes means though SAP
BASIS team, ABAP and DB Team will help in analysis which they must be knowing.
The important SAP T Codes for Performance Analysis and Tuning are..
Memory/Buffer Management – ST02
Work Load Monitor - ST03
Database Management – ST04
SQL Trace Monitor & Analysis – ST05
OS Level Monitor – ST06
Work Process CPU Time – SM50
SAP Business Transaction Analysis - STAD

ST02 – Memory/Buffer Management
Session-5Session-5
SAP stores frequently used information in buffers in memory. Transaction ST02 monitors the usage
of these buffers. The most critical factors it reports are hit ratio, free space, and swaps. The hit ratio
is the percentage of requests that can be fulfilled by the information in each buffer (preventing
expensive database requests), and perhaps is the most important statistic on the screen. Free space
measures how full the buffer is, and swaps show how many times data had to be removed from the
buffer to make room for other data.
The Hit Ratio of the Single Record Buffer increases very slowly from system startup: therefore, a hit
ratio less than 90% is a concern only if there is no free space left in the buffer.
Low hit ratios are not always due to a performance problem, as an example, a transport into a
system can reduce hit ratios.

Session-5Session-5

CPU : If the average CPU load exceeds 75%, temporary CPU bottlenecks are likely to occur. An average CPU load
of more than 90% is a strong indicator of a CPU bottleneck.
Memory : If your hardware cannot handle the maximum memory consumption, this causes a memory
bottleneck in your SAP system that can impair performance. The paging rating depends on the ratio of paging
activity to physical memory. A ratio exceeding 25% indicates high memory usage (if Java has been detected 0%)
and values above 50% (Java 10%) demonstrate a main memory bottleneck
Session-5Session-5
Parameter Requireme
nt
Measuri
ng Tool
Description
Hit Ratio*** >95% ST02 Percentage of requests filled by
SAP buffer (memory) and not disk.
Free Space >5% ST02 the unused space percentage in each
buffer
Free Directory >5% ST02 free directory percentage in each
buffer
Swaps <3 ST02 number of times an object was
swapped from a buffer to make
room of another object

ST03 or ST03N- Workload Monitor & Analysis
The ST03 Workload Monitor is the central access point for analysing performance problems
in the SAP system. ST03N is a revised version of transaction ST03. In current SAP Releases
transaction ST03N replaces transaction ST03 and is automatically started when you enter
transaction code ST03.
Here you can compare the performance values for all instances, and compare the
performance of particular instances over a period of time. Due to the number of possible
analysis views for the data determined in transaction ST03 , you can quickly determine the
cause of performance problems.
Transaction ST03 records the response time of the system and of individual transactions. It
can be used to see how fast the system is responding. ST03 also divides response times into
CPU time, wait time, load time, and database request time. These times will be evaluated as
a percentage of Average Response Time (ART) for each server during each test so that it can
be determined where increases occur
Session-5Session-5

You can use the workload monitor to display the following, among other things:
Number of instances configured for your system and number of users working on
the different instances
Response time distribution, Number and volume of spool requests.
Distribution of workload by transaction steps, transactions, packages, sub
applications, and applications
Transactions with the largest response times and database time
Memory usage for each transaction or each user per dialog step
Workload caused by RFC, broken down by transactions, function modules, and
destinations
Statistics about response time distribution, with or without the GUI time
Session-5Session-5

Following are the parameters that should be measured and focused using ST03 T code with
the below threshold measurements.
Session-5Session-5
Parameter Requireme
nt
Measuri
ng Tool
Description
Average Response
Time
(ART)
<1 second
(<1000
ms)
ST03n Response time of a dialog step.
Excludes network transmission time
from application server to
presentation layer (SAPGUI)
Average CPU Time <50% of
ART
ST03n CPU time per dialog step
Average Wait time <1% of
ART
ST03n dispatcher queue time per dialog
step
Average Load time <10% of
ART
ST03n load time per dialog step
Average DB
request time
<50% of
ART
ST03n database request time per dialog step
Direct Reads <10ms ST03n average time for direct reads per
dialog step
Sequential Reads <40ms ST03n average time for sequential reads per
dialog step

Session-5Session-5
ExpsExps

One more example is depicted below for SAP HR module to analyze & monitor the dialogue and user steps executed for
the performance test execution, the STO3n T code is used and drilled down to the required HR module for the analysis.
This transaction is critical as it helps to calculate the volume of transactions carried out during the elapsed time of
performance test execution. The below screen shows the total number of dialogue user & report user steps executed
for each HR transactions/T codes PA20, PA30, PA40, P013, PP01 for dialogue user steps where as remaining two
transactions are report user steps.
Session-5Session-5

ST04 -Database Management
Transaction ST04 reports detailed database usage statistics. The Technical team will watch
the buffer, recursive calls, parsed calls, and sorting on this screen. Recursive calls are a result
of low DD (Data Dictionary) cache and parsed calls are a result of low library cache, both
indicate deficiencies in the Shared Pool size.
The Database Monitor shows specific information related to the current performance in
the database interface. Almost everything going on in the database will be presented here.
Data buffer allocation, Hit Ratio, DB Connections, CPU Times, Index utilization, Database files
status and utilization.
Session-5Session-5
Parameter Requireme
nt
Measuri
ng Tool
Description
Data buffer busy
waits
<5% of
reads
ST04 ratio of data buffer busy waits to
reads
Recursive Call
Ratio
<10% ST04 ratio of recursive calls to user calls
Parsed Call Ratio <25% ST04 ratio of parsed calls to user calls
Sorting Ratio <5% ST04 ratio of disk sorts to memory sorts

ST04 -Database Management
Session-5Session-5

ST05 - SQL Trace & Analysis
Using this T code we can trace all the activity for a user and for each & every program. The output from
ST05 will show the SQL statement.
How many records it selects and is bringing from the database.
The DECLARE, PREPARE, OPEN,
REOPEN, CLOSE and FETCH operations
that will be recorded during the Trace
so that later on when performing the
analysis it will be of great help.
The execution plans, index advising,
sorting of similar statements or
duplicated ones, sorting per tables and
much more.
Session-5Session-5

ST06 – Windows OS Level Analysis & Monitoring
This T code is used for for analysing all the operating system values related with
CPU utilization
Disk drive information,
Network,
OS Swapping etc
by means of the OS Collector (saposcol) service. With this tool, we can observe if for a
particular drive the response time is excessively high or, on the other hand, if disk drives are
performing well.
We should use this tool in order to understand if a performance issue needed to be tackled
from a hardware bottleneck perspective.
The screen shot of the using this code is shown in the next slide..
Session-5Session-5

ST06 – Windows OS Level Analysis & Monitoring
Session-5Session-5

SM50 - WORK PROCESS CPU TIME
Transaction SM50 should be used to gather information about CPU times used by each work
process in the application and database servers during the test.
To calculate CPU times during each test, the cumulative CPU time of each work process before the test
was subtracted from the cumulative time after the test (shown in ss:hh = seconds, hundredths of
seconds).
The CPU usage of work processes gives an idea of the proper number of work processes a server
needs. If all the work processes of a particular type (like all the dialog work processes) use large
amounts of CPU time, more work processes of that type are possibly needed.
Conversely, if some work processes have a very small change in CPU time, they can possibly be removed
from the configuration.
Session-5Session-5

This is one of the one top tool every administrator, developer and consultant needs to be familiar , SM50
is the main process monitor. From the screen in next slide we will be able to see almost everything that
is currently running in SAP system. You can also see detailed information on a particular running process,
the developer trace and dispatcher trace and you can change trace level and component to perform a
trace on.
When we are working in a performance issue or even if you are analysing something, SM50 will help.
As a preview, from this screen you can see if the process is doing a Sequential or Direct read over a
database table, what user is currently running
What report,
How long it is running, etc.
In the details screen, we can see information such as how many records were written, read, inserted or
deleted, and the current SQL statement or procedure as shown in the next screen below.
Session-5Session-5

Session-5Session-5

STAD – STATS Collector
The statistical records collect information individually for each transaction step such as
Response times
Database times
Network times
Wait times
Front-end times
The data will be stored in a flat file at the operating system level known as the statistical file. This tool
will help understand in detail where the performance spike is located by analyzing the transaction
activity step by step.
Information like how many database records were selected, updated or inserted and in which database
tables(if activated), what program name was executed, what screen name and screen number was called
and so on.
With the Statistical Records we should be able to understand when the problem is being observed for
an averaged, high response time transaction. We will then know how to address that specific
performance issue
Session-5Session-5

STAD – STATS Collector
Session-5Session-5

SAP Performance Tuning Approach
Before we complete this final session, I would like to discuss the various approach of fine tuning the SAP
system in general as described below..
While we carry out the performance test execution & analysis we will definitely come across various
situations and following are the some of the questions that should be raised by the performance
consultants to the project stakeholders during the consultancy activities.
Do you have a performance issue with a specific transaction ? Or
Is the performance good but you need it even faster to fit your business requirements?
Do you want to increase your system performance in general or
Just for a specific task type/reports/batch jobs and Interface?
Do you want to check the current (hardware) system to deliver more performance in general?
Session-5Session-5

SAP Performance Tuning Approach
In order to answer the above queries, I would recommend the following three different approaches in
order to isolate and address the performance issues in SAP landscape. But it is necessary to understand
when and why to use which approach first.
Analysis and tuning of a specific SAP transaction
Analysis and tuning the general SAP system performance
Analysis and tuning the SAP system landscape performance by better hardware utilisation
Note that SAP performance tuning is "time-consuming" at the first time, but if you keep track of it in a
continuous process – We can run the SAP system faster and more stable with less hardware.
Some folks answer like we will buy bigger and faster hardware to solve our performance issues. Ok fine
which will work for a period of time, but at some point you can not beat the performance issues with
hardware only and even with "expensive" hardware platforms it is quite questionable.
The above three approaches are explained in detail in my next slides..
Session-5Session-5

SAP performance testing & engineering courseware v01

SAP performance testing & engineering courseware v01

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à SAP performance testing & engineering courseware v01

Similaire à SAP performance testing & engineering courseware v01 (20)

Dernier

Dernier (20)

SAP performance testing & engineering courseware v01