1. SAP Performance Testing Best Practices Guide BEST PRACTICES FOR SAP R3 PERFORMANCE TESTING By SURYAKANTH KELMANI Performance Engineering Practice Wipro Technologies Version No. Author Revision Description0.1 Suryakanth Kelmani Initial draft issued for internal review0.2 Suryakanth Kelmani Added the SAP Performance Test Lab setup0.3 Suryakanth Kelmani Updated with the Monitoring T codes and Batch jobs execution results0.4 Suryakanth Kelmani Updated with SAP performance testing methodology.0.5 Suryakanth Kelmani Added SAP WEB correlations Wipro Performance Engineering Practice

2. SAP Performance Testing Best Practices Guide TABLE OF CONTENT1. INTRODUCTION ......................................................................................... 3 1.1 OBJECTIVE ................................................................................................ ........................... 3 1.2 PERFORMANCE TESTING FRAMEWORK ......................................................................... 32. PLANNING .................................................................................................. 4 2.1 BUSINESS STREAMS: ................................ ................................ ................................ .......... 5 2.2 TEST ENVIRONMENT ................................ ................................ ................................ .......... 8 2.3 TEST DATA MANAGEMENT ................................ ............................................................... 9 2.4 TEST TOOL & SETUP ................................ ..........................................................................103. BUILD / TEST SCRIPTS DESIGN............................................................. 12 3.1 SERVER SIDE SETTINGS ................................ ....................................................................12 3.2 CLIENT SIDE SETTINGS .....................................................................................................124. EXECUTION.............................................................................................. 15 4.1 EXECUTION OF ONLINE USERS In SILO .......................................................................15 4.2 EXECUTION OF BATCH JOBS & REPORTS In SILO ......................................................15 4.3 APPROACH FOR BATCH JOBS PERFORMANCE TESTING .............................................15 4.4 EXECUTION OF ONLINE USERS AND BATCH JOBS & REPORTS (Combined) ..............17 4.5 RUN TIME SETTINGS FOR EXECUTION: ................................ ................................ .........17 4.6 SCHEDULE BUILDER ................................ ................................ ................................ .........185. MONITORS & ANALYSIS......................................................................... 19 5.1 SAPGUI MONITOR ................................................................................................ ..............196. SAP PERFORMANCE MEASUREMENT & METRICS ............................ 22 6.1 WORKLOAD ANALYSIS .....................................................................................................22 6.2 MEMORY/BUFFER MANAGEMENT ................................ ................................ ..................22 6.3 DATABASE MANAGEMENT ................................ .............................................................. 23 6.4 UNIX SERVERS (OS Parameters, CPUs, Memory) ................................ ................................ 237. SAMPLE GRAPHS..................................................................................... 24 7.1 UNIX RESOURCE GRAPH ................................ ................................ ................................ ...24 7.2 EXECUTIVE SUMMARY GRAPH ................................................................ ....................... 25 7.3 AVERAGE RESPONSE TIME GRAPH FOR T CODES ................................ ........................25 7.4 BATCH JOB/INTERFACE SAMPLE REPORT .....................................................................268. APPENDIX ................................................................................................. 26 A. LOADRUNNER HARDWARE & SOFTWARE .................................................................26 B. SAP T CODES & ITS FUNCTIONS ...................................................................................26 C. SAP WEB CORRELATIONS ................................................................ ............................. 27 D. REFERENCES ...................................................................................................................28 Wipro Performance Engineering Practice

3. SAP Performance Testing Best Practices Guide1. INTRODUCTION1.1 OBJECTIVE The objective of this document is to detail the best practice, approach & planto be followed for the Performance testing of SAP application and to make sure thatthe team member who is going to carry out performance test activities can quicklyrefer and implement the best practice followed across all phases of performancetesting. This document is intended to guide further Volume Test Planning, tool setup,Script Preparation, Execution & Result analysis activities of Performance test phase.1.2 PERFORMANCE TESTING FRAMEWORK The below diagram depicts the robust & proven performance testingframework for SAP performance testing, each phase has the detailed activities thatneeds to be carried out and the output or deliverables at the end of each phase asshown in the fig below. Activities of each phase are explained in the below sections... Performance Testing Framework Wipro Performance Engineering Practice

4. SAP Performance Testing Best Practices Guide2. PLANNING The objective of planning phase is to identify tasks, pre-requisite anddependencies that is required to carry out performance testing. Planning phase shouldexplain what are the activities you are going to do and how we are going to plan inorder to get these task done, what ever activities we do identify in this phase shouldbe noted down and put these tasks on priority basis.The key tasks involved in this phase are: Prepare the performance test approach Identify the critical transactions, volumes, user base and define their SLAs. Identify the environment and tools required Identify test data requirements Prepare a detailed Project plan with miles stones and the deliverables. Performance test approach document will specify the approach taken to carryout performance test, scope of testing, environments and tools used, inputs,dependencies and deliverables of the Performance testing phase. Information regarding critical transactions for each work stream, theassociated volumes and the concurrent user information is expected to be madeavailable by the business team in the form of NFR (Non Functional Requirements)document. This NFR should contain the data like Concurrent Users, Critical T Codes,batch Jobs, Volume of transactions, transaction response time, batch executionwindow etc. There are two different categories of business process types we need toidentify in order to have smooth execution of the project, they are divided into Onlineusers and Batch Jobs/Interfaces/Reports. You cant just neglect Batch jobs whichplays an important factor in successful of SAP performance testing. Like online users,critical & data intensive batch jobs needs to be identified along with Online users, thebatch jobs time window, the SLAs for batch jobs how many number of records eachbatch jobs should be processed, the important success factor for batch jobs executionis that, are the batch jobs able to execute n number of records within the specifiedtime window, for example Print batch jobs able to print thousands of records within 1hour. During this planning phase please note that there will be other parallelactivities that can be carried out, like identification of environments as well as thetools for performance testing, test data analysis, work load profiling etc. Performancetesting is normally carried out on an environment that is representative of theProduction environment in terms of hardware, software configuration and databasesize. Performance test tools will be used to generate scripts and simulate user load onthe system under test. Please note that HP Load Runner will be the best tool that canbe used for SAP performance testing as its also been widely used & recommended bySAP. It is necessary to have Production size data in order to get accurate test results.There is a dependency on the other team like Data Migration to provide the requiredvolumes of data for carrying out performance testing. During planning phase, test data Wipro Performance Engineering Practice

5. SAP Performance Testing Best Practices Guiderequirements like material number, customer account, GL account, Sold to Party,WBS Cost centre, etc will be identified and communicated to the Functional Team orData Creation Team. SAP system has several Business Streams like Sales & Distribution, FinancialAccounting, Supply Chain Management, SRM, Record To Report RTR, HR, RealEstate, Material Management etc and these are called business streams in SAPlanguage and given below are the example for 4 business streams identified for one ofthe Energy & Utilities client for performance testing.2.1 BUSINESS STREAMS: The following 4 streams ( for example, it could be more ) were identified forperformance testing of SAP application, each streams transaction codes ( T codes)were identified with critical and most frequently used on daily basis also dataintensive in nature as shown in the below tables for each streams. Again these shouldbe put them into Online and batch jobs category.SALES & DISTRIBUTION (SD): Create an order with five line items. (VA01) Create a delivery for this order. (VL01N) Display the customer order. (VA03) Change the delivery (VL02N) and post goods issue. List 40 orders for one sold-to party. (VA05) Create an invoice. (VF01)Note: Each benchmark user has his or her own master data, such as material, vendor,or customer master data to avoid data-locking situations.Dialog Steps0. Logon 10. Choose Enter1. 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 Enter5. Choose Save 15. Call /nVF01 (Create invoice)6. Call /nVL01N (Create a delivery) 16. Choose Save7. First screen 17. Call /nend8. Choose Save 18. Confirm log off9. Call /nVA03 (Display customer order) Wipro Performance Engineering Practice

6. SAP Performance Testing Best Practices GuideUser interaction steps 2 - 16 are repeated n times (15 user interaction steps --> min.150 sec. duration).FINANCIAL ACCOUNTING (FI):Dialog Steps0. Logon 11. Select first line1. Main screen 12. Call Post incoming payments2. Call Post Document 13. Enter header data3. Create customer item 14. Choose Process open items4. Create general ledger account item 15. Select item 5 of the list5. Choose Post 16. Scroll down to the end6. Call Display document 17. Select last item7. Enter previous posted document 18. Deactivate all selected items8. Double-click first line 19. Choose Post9. Call Customer line item display 20. Call /n end10. Enter data and choose Execute 21. Confirm log offUser interaction steps 2 - 19 are repeated n times (15 user interaction steps --> min.180 sec. duration).EMPLOYEE SELF-SERVICE PORTAL (EP-ESS):User Interaction Steps of the EP-ESS1. Log on to the portal Welcome page 6. Choose Address(includes three iViews)2. Choose Working Time > Record 7. Choose Bank InformationWorking Time3. Choose Leave Request 8. Choose Benefits and Payment > Paycheck Inquiry4. Choose Leave Request Overview 9. Log off from portal5. Choose Personal Information >Personal Data Wipro Performance Engineering Practice

7. SAP Performance Testing Best Practices GuideSeven different business transactions are launched per loop (steps 2 - 8). Every loop isrepeated n times for each user. The user think time is 10 seconds; thus, one loop takesat least 70 seconds.MATERIALS MANAGEMENT (MM)The Materials Management (MM) Benchmark takes you through a series of steps tocreate a purchase requisition for five materials (transaction ME51N), a purchase orderfor the five materials (ME21N), a goods receipt (MIGO), and an invoice (MIRO) forthe purchase orderDialog Steps0. Logon 10. Choose Execute1. Main screen 11. Choose Post2. Call /nME51N (Create purchase 12. Call /nMIRO (Create invoice), enterrequisition) company code3. Enter data 13. Enter basic data4. Choose Post 14. Choose Payment5. Call /nME21N (Create purchase order) 15. Enter data6. Enter data 16. Choose Post7. Choose Post 17. Call /nend8. Call /nMIGO (Goods receipt purchase 18. Confirm log offorder)9. Enter dataUser interaction steps 2 - 16 are repeated n times (15 user interaction steps --> min.150 sec. duration).Like online critical transactions as depicted above, I have also mentioned some of thebatch jobs names which we identified as critical for the performance test executionduring one of the SAP performance testing project. Wipro Performance Engineering Practice

8. SAP Performance Testing Best Practices Guide My suggestion to the members of the performance testing team to go throughthe business process involved in testing as many times as possible and get familiarwith the business process/flow and note down the required data that is going to beused in test scripts, this will help them to proceed with much confidant and createmore robust scripts with the accurate data.2.2 TEST ENVIRONMENT Ideally, the simulated load and the hardware used for the volume test shouldbe identical to the load and hardware of subsequent production operation. However,for various technical, organizational or economic reasons, it is not always feasible tosimulate the full load expected in subsequent production operation. In addition, it isnever really possible to execute the test on hardware exactly identical to the hardwareplanned for production. But, as a best practice performance testing should be carried out on anenvironment which is mimicking close to the production environment hardware andsoftware configuration, the next better option is to execute performance test onproduction environment before its Go Live, i.e. this should happen at least 6 weeksbefore the Go Live so that you can make use of the best. Please note that dont try todo performance testing on any other environment which is not at all close orequivalent to production like. Important Note: Make sure that the hardware used for the volume test isexclusively reserved for this purpose while the volume test is run. In-parallel usage ofthe 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 ofits results. Note that the SAP system will exchange data with a number of internal andexternal non-SAP systems, i.e. Interfaces and Non SAP systems like BACS, PAYMatrix, Billing System, Cyber Source etc.. In order to carry out Performance testing,it is essential to connect to the test environments of all the systems identified duringtesting. Wipro Performance Engineering Practice

9. SAP Performance Testing Best Practices Guide In an SAP Landscape a typical test environment consists of the followingcomponents as shown in the below mentioned lines. ECC 6.0(ERP Central Component) SRM 5.5 (Supplier Relationship Management) SCM FICO/HR/SD/MM/MDM/PM etc PI 3.0(Exchange Infrastructure earlier Known as XI) BI Business Intelligence EP (Enterprise Portal) And other Non SAP system integrated with SAP2.3 TEST DATA MANAGEMENT The data required for Performance testing should be identified during thePerformance test planning phase. The data to be set up within SAP as well as the datarequired connecting and test with external systems will be defined. Since database tables (especially transaction data tables) start to grow afterstart of production, database accesses that are not fully specified tend to get slowerand more resource-expensive. If the volume test is performed with almost emptydatabase tables, the response times in subsequent production operation will be higherthan measured in the volume test. Therefore, for the volume test to be meaningful,you need to populate the database tables with representative data that is both masterand transactional data. We must understand & set the expectation to the stakeholders that which teamis going to provide all valid transactional data and who is going to create various userids and passwords with proper roles & authorizations for the realistic simulation ofuser load. For example all HR user ids cant have Sales & Distribution Roles, and allSCM user ids may not have HR roles and authorizations.Some of the example below shows what data is required during performance testing.. Master Data, o Customer Account Number o Sold To Party o WBS Cost Element o Material Number o Employee Number etc. Transactional Data o Bank A/c number o User Name o GL Account Number etc. User Data o Delivery Date o Material Price o Customer Name etc. Wipro Performance Engineering Practice

10. SAP Performance Testing Best Practices GuidePlease note that the user ids and password for emulation of the load should be createdby the Tech arch team or BASIS team (SAP back end administrators are called asBasis), make sure that the team creates the user ids with appropriate namingconventions so that each users can be identified in the back end of the system duringperformance testing as shown in the examples below.Sales & Supply Supply Chain Enterprise Finance &Distribution SD Resource Management Portal EP Accounting Management SCM FI SRMSD0001 SRM0001 SCM0001 EP0001 FI0001SD0002 SRM0002 SCM0001 EP0002 FI0002.. .. .. ..SD0200 SRM0400 SCM0150 EP0800 FI0300Any data (Transaction data, user data etc) that is required during performance testingwill be provided by each business streams.2.4 TEST TOOL & SETUP The diagram below shows that the performance test lab setup which make useof 4 Load injectors (Load generators) with one Loadrunner Controller, all the m/c areconnected to each other on a business LAN which has access to SAP system, eachsystem has the 2GB RAM with Intel CPU speed 2.8GHz. Please note that the machine running a scenario with SAPGUI Vusers musthave a Loadrunner typical installation. Running Vusers from machine with only thecontroller installed is NOT SUPPORTED, and each Loadrunner systems (Injectorsand Controller m/c) should have the SAPGUI client installed so that they can talk toback end SAP ECC system. LoadRunner is HP (formerly Mercury Interactive) load/performance testingtool. It operates using a record/replay method in which the software allows a user torecord a business process and then replay it. LoadRunner can simulate many users onthe system at once. It accomplishes this by capturing all data that passes from theclient machine to the SAP server and back while recording. When replaying the script,LoadRunner sends the same data that it captured back to the server, thus performingthe exact same business processes that were recorded thus by emulating real users. Wipro Performance Engineering Practice

11. SAP Performance Testing Best Practices Guide Fig.1 Performance Test Lab Setup with the Environment Terminal Services: Machine running SAPGUI Vusers may be limited in thenumber of Vusers that can run, due to the graphic resource available on that machineand due to the limitations imposed by Microsoft windows on GDI objects and userobjects.To rectify the above mentioned issue and allow more SAP users to be run, it isrecommended that multiple Terminal Server sessions be run on the load generatormachine (Injector) and relate each terminal server session to the load generator. Thismeans a Terminal Server must be running on the load generator. Please note that you can run maximum of 30 to 50 SAPGUI users on eachterminal session, MS Windows 2003 server Standard edition should be installed oneach Load Generators machine in order to run terminal sessions, by default you canhave three terminal session run on each machine, so with this 3X50=150 total userscan be run each m/c, if you want to run more sessions then you need to buy thelicense from MS vendor in order to increase the session which helps you to run morenumber of SAPGUI users.Let us recap the following points in order to complete the Planning phase,The main activities in test preparation phase include: Identification of Test Scenarios for Batch job window Identification of Test Scenarios for On-line users (SAPGUI and Portal users) Set up and configure the Production environment with test data. Wipro Performance Engineering Practice

12. SAP Performance Testing Best Practices Guide Test Plan & approach document NFR (Non Functional Requirements)The success factor: NFR document Sign-off Performance test plan & approach document sign-off by the stake holders. Tools & Environment Setup completion. Identification of Test Data. Test Data Management3. BUILD / TEST SCRIPTS DESIGN Once the planning phase is in place and signed off from the business, with theinput from NFR and from the functional team, its time to design work load module &develop automated scripts in order to simulate the real users. Before we startscripting, we need to change some settings on the SAP server which enables theautomated tool to record user actions on SAPGUI protocol.3.1 SERVER SIDE SETTINGS Before you start recording in the tool, you need to set certain parameters inSAP server in order to generate the script Enabling scripting on Server Side: By default, the scripting API is disabled in SAP R/3 system,. To enable scripting API, For all users of a given system, the system administrator needs to set the sapgui/user_scripting profile parameter to TRUE on all the application servers and make sure that the above value TRUE should be in upper case, The administrator needs to use the T code RZ11 in order to change the above profile parameter.3.2 CLIENT SIDE SETTINGS Enabling scripting on Client Side: You need to enable Scripting as circled in the red colour in the screen shot below and disable all check boxes as shown in the screen shot shown below. In order to do this, log on to SAP server, select the Rainbow Icon and select Options. And you must disable the remaining two check boxes 1. Notify When a Script attaches to a Running GUI 2. Notify When a Script Opens a Connection Wipro Performance Engineering Practice

13. SAP Performance Testing Best Practices GuideConfiguring the Model Dialogue Boxes for F1 and F4-Client Side:a) For F1 In order to configure this option, Log on to the SAP serverHelpSettings, select F1Help Tab and select the in modal dialog box (R/3) option inthe display section as shown in the screen shot below. Wipro Performance Engineering Practice

14. SAP Performance Testing Best Practices Guideb) For F4 To open F4 help in model dialog boxes, the following procedure must becompleted by a SAP administrator. Choose Help>Settings. Click the F4 Help tab. In the Display section (Bottom Left), choose system defaults. In the display portion of the system defaults sections (bottom right). Select theDialog. Click on the pencil icon first before you can change the sections. Click on theicon again to save lock the selection as shown in the screen shot below Once the above settings are configured on the SAP App Server, please selectSAPGUI protocol for creating SAPGUI scripts and SAPWEB protocol for creatingEnterprise Portal scripts. The scripting for SAPGUI users and SAPWEB users arequite simple and not to worry much about scripting part as its 80% direct record &Replay with very few code enhancements in SAPGUI, and few complex correlationsin SAP web EP applications. There is not at all correlation concept in SAPGUI exceptcapturing the o/p of one process and input the same value for next process, for thisyou can use Loadrunner sapgui_get_Status_bar () functions. Once the test scripts are developed and enhanced to meet the businessrequirements, parameterise various data, correlating the dynamic values etc, thesescripts should be run for various iterations with different data inputs and cross checkwith the records created in the back end of the system. Once you have confirmed thatall scripts are doing what its intended to do, then get these scripts run with thebusiness team to confirm that they are in line with the NFR and satisfies theirrequirements. At this point of time, ask the Functional team to identify the Batch & Schedulethe batch jobs for the batch execution window, usually these batch jobs are scheduled Wipro Performance Engineering Practice

15. SAP Performance Testing Best Practices Guideand executed by Functional Team either manually or by using some tool likeController M ( is a batch job work load scheduler tool )The success factor: Successful development & Replay of Automated Test Scripts. Make sure that you use coding standards implemented in all the scripts. Automated Test Scripts Sign-off by Business Team. Production like setup batch jobs scheduled on the test environment. Batch jobs are successfully smoke tested.4. EXECUTION The approach for performance test execution will be carried out in thefollowing manner, and it should look like this as shown below. Performance Testing of Online Users (Individually for Online users) Performance testing of Batch Jobs (Individually for Batch Jobs) Combine Online Users and Batch Jobs together and execute together4.1 EXECUTION OF ONLINE USERS In SILO Once the test scripts development is completed then all the above identifiedstreams like S&D, FI, EP(ESS) and MM should be executed in Loadrunner controllerfor their respective concurrent loads and analyse the result of each execution to findany bottlenecks in the stream wise. Please note that the execution of these streamsshould be done in isolation of each stream (i.e. stream S&D T codes should beexecuted individually in isolation of other streams). This helps the project team to findany performance bottleneck in the early phase of the performance test execution. After successful execution of individual streams, its now time to execute allstreams together for concurrent number of users defined in the NFR and analyse theperformance of the system overall4.2 EXECUTION OF BATCH JOBS & REPORTS In SILO Batch performance models will be built to represent the average and peak load ofbatch processing in SAP systems. Batch scheduling (Functional) team will define theproduction batch schedule and estimate average and peak load. This helps the team to know ifany batch jobs & Reports are taking much time and not fitting the batch window (Forexample 10PM to 2:00AM ).Batch performance model will include the daily batch jobs running in ECC, BI, SCM, SRM,XI, and JCAPS etc4.3 APPROACH FOR BATCH JOBS PERFORMANCE TESTINGBelow is the detailed approach for Batch jobs performance testing..Objective v Check batch job performance in ECC XX environment. To ensure current level of performance.Pre-requisite v Deployment of Control M* and related application on the pre production environment for the identified critical interfaces. Wipro Performance Engineering Practice

16. SAP Performance Testing Best Practices Guide v End to End connectivity setup for flow. v Charged day identification for data recording/ input file for the batch jobs. v Configure monitoring tools on ECC XX to capture the performance metrics for the batch executions.Approach v Capture batch job baseline data of selected interface from the current ECC system. v All the critical batch jobs which are to/from the SAP system should be considered ( including third party systems) v Trigger Job on SAP ECC system using Control M for reference measurements v Use the input file and process in ECC XX Environment v Trigger Job in ECC XX system using Control M for validation v Tuning if required v generate performance report*Please note that Control M is batch job scheduler tool like AppWorkxA typical 24 hrs batch jobs approach is depicted in the below diagram, whichillustrates the batch jobs executions in SAP and Non SAP integrated environment,please note that the batch jobs should be given much importance as process largeamount of data to/from the SAP & third party applications and they need to meet theperformance requirements/KPIs as per the NFR document. Fig: Typical Batch Jobs executions in SAP performance testing Wipro Performance Engineering Practice

17. SAP Performance Testing Best Practices Guide4.4 EXECUTION OF ONLINE USERS AND BATCH JOBS & REPORTS (Combined) After completion of performance test execution for online users and Batch Jobs, weneed to combine both the scenarios Online Users & Batch jobs to emulate the real scenarioand measure the system performance of SAP R/3. The below screen shot shows how the scenarios with the load generator looklike, please note that all the load generators sessions are running on MS terminalserver sessions and each session is mapped with their respective names like as shownin the screen shot below.4.5 RUN TIME SETTINGS FOR EXECUTION: The below screen shot shows the various RunTime Settings for the scenariosexecutions, its important to apply these runtime settings to in order to execute thescenario successfully. General: Run Logic No Change Pacing With fixed delay of 40 seconds. (Depends) . Log Standard Log Think Time Replay Think Time, use random percentage with Min 100% Max 150% with Limit Think Time to 10Sec Wipro Performance Engineering Practice

18. SAP Performance Testing Best Practices Guide Additional attributes No Change Miscellaneous Run Vuser as Thread SAPGUI: General Disable Show SAP client during Replay Network: Speed Simulation Use Max Band Width.4.6 SCHEDULE BUILDER Go to Edit Schedule and Set the following settings in the schedule builder asshown below. RampUp: Start 5 Vusers for every 30 Seconds. Duration: Run for 5 Hours (depends up which test you are doing, for example duration should be 12 to 24 hours). RampDown: Stop 5 Vusers for every 60 Seconds. Wipro Performance Engineering Practice

19. SAP Performance Testing Best Practices GuideChecklist before execution:HP LoadRunner script testing will occur after creation of each automated script.Scripts can be added to performance test bed when: 1. No scripting errors occur. 2. Looping successfully; replaces parameterization variables with various values. 3. Activity is noted on each system tier. 4. A minimum load of ten users is simulated. 5. Scripts are run on a subsequent day (dates correlated correctly).5. MONITORS & ANALYSISYou need to configure the following monitors in order to analyse the loadrunnerresults, if you dont have SAPGUI monitor license then you can ask the Basis team tomonitor the application through CCMS tools (using STO3n Tcode) which will givesame data as of SAPGUI and Database Monitors. SAP Monitor (SAPGUI Monitor) UNIX Resource Monitor. Oracle Database Monitor Windows Monitor for WAS server5.1 SAPGUI MONITORThe following measurements will be taken for each script as it is executed inLoadRunner:Response time: This starts when a user request enters the dispatcher queue; ends when the next screen is returned to the user, this will measure the end to end response from the client to the system Wipro Performance Engineering Practice

20. SAP Performance Testing Best Practices GuideWait time: This is the time a user request sits in the dispatcher queue.Roll-in time: This is the amount of time needed to roll user context into the work process.Load time: This is the time needed to load from the database and generate objects like ABAP code, CUA, and screen information.Processing time: This is the time spent in the work process executing ABAP code.Database time: Starts when a database request is put through to the database interface; ends when the database interface has delivered the result.CPU time: This is the total CPU time used by the SAP R/3 work process. The SAP monitor displays statistics about the resource usage of a SAP R/3system during the scenario or session step run. This monitor is appropriate for SAPR/3 server and SAPGUI (version 6.20 or later) environments. SAP GUI transactions help the tech arch team and performance team toquickly isolate the performance issues within the SAP R/3 infrastructure, and toauthoritatively delegate problem resolution to the right SAP application teams.The solution provides a layered breakdown of performance of SAP R/3 transactionsinto database, system, processing, and interface layers.Database layer shows the amount of time spent by an end-user business process or anindividual dialog step in the database tier.System layer shows a breakdown of time the dispatcher is waiting for a free workprocess, time taken to load or generate ABAP programs by the work process, timetaken to associate the user context with a work process, and time taken to save usercontext data on the outbound path.Processing layer shows the amount of actual time taken by the work process toprocess the ABAP programs and SAP application server.Interface time refers to the performance characteristics of accessing external systems -either SAP or non-SAP such as Remote Function Call time.Below diagram shows the break down of each layer and this should help the team tofind out the root cause of the bottleneck. Wipro Performance Engineering Practice

21. SAP Performance Testing Best Practices Guide5.2 UNIX RESOURCE MONITOR UNIX monitor gives the system resource parameters of Unix server box, inorder to run UNIX monitor successfully on Loadrunner controller, you need to runrstatd daemon service on Unix server box, you can ask database admin team to set thisservice running, or else you can ask him to carry out the following steps as shownTo configure the rstatd daemon:1 Run the command: su root2 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 thecomment directive, and save the file.3 From the command line, run:Kill -1 inet_pidWhere 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 therstatd daemon.4 Run rup again.If the command still does not indicate that the rstatd daemon is configured, contactyour system administrator.PS: You can configure the remaining monitors like Oracle Database and Windowsresource monitor just by adding their respective IP addresses. Wipro Performance Engineering Practice

22. SAP Performance Testing Best Practices Guide6. SAP PERFORMANCE MEASUREMENT & METRICS The following activities should be planned for the performance test: Use the SAP system monitoring procedure to check the peak hours activity. Identify long running jobs and run it to test server performance. Run critical business transactions and measure runtime. Define peak hours and the system to be monitored during execution in order to identify performance problems. The monitoring should be done using SAPs Comput ing Center Management System(CCMS) and the UNIX utility vmstat. CCMS provides performance monitors that trackvarious aspects of the SAP systems while the vmstat provides detailed operating systemperformance information. SAP system performance actually depends on many factors such as modulesimplemented, database size, and number of users. Because of this, there are no standardvalues that constitute good performance. However, based on experience and SAPrecommendations, the Technical Architecture Team has determined the following stress testperformance metrics are indicative of satisfactory performance: 6.1 WORKLOAD ANALYSIS Transaction ST03n records the response time of the system and of individualtransactions. It can be used to see how fast the system is responding. ST03n also dividesresponse times into CPU time, wait time, load time, and database request time. These timeswill be evaluated as a percentage of Average Response Time (ART) for each server duringeach test so that it can be determined where increases occur. Parameter Requireme Measuri Description nt ng Tool Average Response