Your SlideShare is downloading. ×
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Loadrunner presentation
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Loadrunner presentation

10,665

Published on

4 Comments
8 Likes
Statistics
Notes
No Downloads
Views
Total Views
10,665
On Slideshare
0
From Embeds
0
Number of Embeds
20
Actions
Shares
0
Downloads
2
Comments
4
Likes
8
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • 13 20 Our recommended rule of thumb when selecting which test cases to automate: The more repetitive the execution, the better candidate the test is for automation.
  • Transcript

    • 1. Load Runner Mercury Performance Test Tool
    • 2. Topics to be Covered
      • Why Performance ?
      • Definitions: Performance Testing
      • Benchmark Design
      • Performance Testing Tools
      • LoadRunner Components
      • What is load testing process?
      • Getting Familiar with Mercury Tours
      • Application Requirements
    • 3. Why Performance…?
        • Does the application respond quickly enough for the intended users?
        • Will the application handle the expected user load and beyond?
        • Will the application handle the number of transactions required by the business?
        • Is the application stable under expected and unexpected user loads?
        • Are you sure that users will have a positive experience on go-live day?
    • 4. Define Stress/Load/Performance Testing
        • Stress Testing : Stress Testing is done in order to check when the application fails by reducing the system resources such as RAM, HDD etc. and keeping the number of users as constant.
        • Load Testing : Load Testing is done in order to check when the application fails by increasing the number of users and keeping the system resources as constant.
        • Performance Testing : The term Performance can mean measuring response time, throughput, resource utilization, or some other system characteristic( or group of them), by varying the number of users.
    • 5. Benchmark Design
      • The Benchmark is the representative workload used during the performance test run. It should be representative of the likely real-world operating conditions.
      • Benchmark is provided by the client.
      • In Industry scenario the benchmark is as follows:
        • No. of transactions passed per second >= 8
        • Response time <= 5 sec.
    • 6. Performance Testing Tools
        • Segue Silk Performer
        • Rational Team Test
        • Mercury Load Runner
        • Empirix e-Load/RSW)
        • Soft Light Site Tools Loader
    • 7. LoadRunner Components
        • The Virtual User Generator captures end-user business processes and creates an automated performance testing script, also known as a virtual user script.
        • The Controller organizes, drives, manages, and monitors the load test.
        • The Load Generators create the load by running virtual users.
        • The Analysis helps you view, dissect, and compare the performance results.
        • The Launcher provides a single point of access for all of the LoadRunner components.
    • 8. What is the load testing process?
    • 9. Getting Familiar with Mercury Tours
        • Opening Mercury Tours
        • Make sure that the sample Web server is running.
        • Open the Mercury Tours application.
        • Log into Mercury Tours.
        • Reserve a flight.
        • End your Mercury Tours session.
    • 10. Application Requirements
      • Mercury Tours must successfully handle 10 concurrent travel agents.
      • Mercury Tours must be able to process 10 simultaneous flight bookings with response time not exceeding 90 seconds.
      • Mercury Tours must be able to handle 10 travel agents running simultaneous itinerary checks with response time not exceeding 120 seconds.
      • Mercury Tours must be able to handle 10 agents signing in and signing out of the system with response time not exceeding 10 seconds.
    • 11. Building Scripts
    • 12. Topics to be Covered
      • Introducing the Virtual User Generator (VuGen)
      • How do I start recording user activities?
      • How do I record a business process to create a script?
      • How do I view the script?
    • 13. Introducing the Virtual User Generator (VuGen)
    • 14. How do I start recording user activities?
      • Open Virtual User Generator.
      • Create a single protocol Web script.
    • 15. How do I record a business process to create a script? First Step: Set Recording Options Recording Levels
    • 16. How do I record a business process to create a script? Contd …
      • Start recording on the Mercury Tours Web site.
      • Login to the Mercury Tours Web site.
      • Enter flight details.
      • Select a flight.
      • Check the itinerary.
      • Click sign off in the left pane.
      • Click Stop on the floating toolbar to stop the recording .
      • Choose File > Save or click the Save button. Type basic_tutorial in the File name box and click Save.
    • 17. How do I view the script?
      • Tree View
      • Script View
      Tree View Script View
    • 18. Playing Back Your Script
    • 19. Topics to be Covered
      • How do I set the run-time behavior?
      • How do I watch my script running in real time?
      • Where can I view a summary of the playback?
    • 20. How do I set the run-time behavior? Choose VUser > Runtime-Settings – Run Logic
    • 21. How do I set the run-time behavior? Contd.. Choose VUser > Runtime-Settings - Pacing
    • 22. How do I set the run-time behavior? Contd.. Choose VUser > Runtime-Settings - Log
    • 23. How do I set the run-time behavior? Contd.. Choose VUser > Runtime-Settings – Think Time
    • 24. How do I set the run-time behavior? Contd.. Choose VUser > Runtime-Settings – Miscellaneous
    • 25. How do I set the run-time behavior? Contd.. Choose VUser > Runtime-Settings – Speed Simulation
    • 26. How do I set the run-time behavior? Contd.. Choose VUser > Runtime-Settings – Browser Emulation
    • 27. How do I set the run-time behavior? Contd.. Choose VUser > Runtime-Settings – Proxy
    • 28. How do I set the run-time behavior? Contd.. Choose VUser > Runtime-Settings – Preferences
    • 29. How do I set the run-time behavior? Contd.. Choose VUser > Runtime-Settings – Content Check Create New Application and New Rule
    • 30. How do I watch my script running in real time? Choose Tools > General Options and select the Display tab.
    • 31. Where can I view a summary of the playback? Go to Execution Log in VUGen screen
    • 32. Solving Common Playback Problems
    • 33. Topics to be Covered
      • What is Correlation?
      • Preparing Mercury Tours for Playback Errors
      • How do I work with unique server values?
    • 34. What is Correlation?
      • Many applications use dynamic values that change each time you use the application. For example, some servers assign a unique session ID for every new session. When you try to replay a recorded session, the application creates a new session ID that differs from the recorded session ID.
      • LoadRunner addresses this issue through correlation . Correlation saves the changing values, in our case the session ID, to a parameter. When running the emulation, the Vuser does not use the recorded value—instead, it uses the new session ID, assigned to it by the server.
    • 35. Preparing Mercury Tours for Playback Errors
      • Open Mercury Tours.
        • Choose Start > Programs > Mercury LoadRunner > Samples > Web > Mercury Web Tours Application .
      • Change the server options.
        • Click SERVER OPTIONS in the left pane. Select the Setting 3 option. Scroll down to the bottom of the page and click the Reconfigure Server Details button. Scroll down to the bottom of the page and click the Return to the Mercury Tours Homepage link. This setting tells the server not to allowduplicate session IDs.
        • (Note that if you have IIS installed on your machine, you will need to modify the settings for this application. Search for the file xitami.cfg in the xitami folder, and open it in a text editor. Locate the line portbase=1000, and modify it to portbase=1001. Save and exit the file.)
      • Close the browser.
      • Record the script again to create a new script with dynamic values.
    • 36. How do I work with unique server values?
      • Record the script again.
      • Replay the script.
      • Scan the script for correlations.
      • View the correlations.
      • Correlate the Session ID.
      • Examine the syntax of the correlation statement.
      • Play the script again.
      • Fix the server configuration.
        • Choose Start > Programs > Mercury LoadRunner > Samples > Web > Mercury Web Tours Application to open Mercury tours.
        • Click SERVER OPTIONS in the left pane. Clear all of the options. Scroll down to the bottom of the page and click the Reconfigure Server Details button.
        • Close the browser.
    • 37. Preparing a Script for Load Testing
    • 38. Topics to be Covered
      • How do I measure business processes?
      • How do I emulate multiple users?
      • How do I verify Web page content?
      • Did my test succeed?
    • 39. How do I measure business processes?
      • Creating Transactions – Re-Record the script using
      • Transactions
      • The transactions would be created for the following pages:
      • URL Access
      • Login
      • Flight Button click
      • FindFlight_Continue_Button
      • SelectFlight_Continue_Button
      • Purchase Flight Button
      • Check Itinerary
      • Log Off
    • 40. How do I emulate multiple users?
      • Parameterization – Step1
      Right Click the text
    • 41. How do I emulate multiple users? Contd..
      • Parameterization – Step2 – Select or Create Parameter
      Type the parameter name Click the button
    • 42. How do I emulate multiple users? Contd..
      • Parameterization – Step3 – Parameter Properties
      Select Parameter Type Create File
    • 43. How do I emulate multiple users? Contd..
      • Parameterization – Step4 – Define Parameter and Close
    • 44. How do I emulate multiple users? Contd..
      • Parameterization – View Parameter
    • 45. How do I verify Web page content?
      • Checkpoints – Two Types
      • Text Checkpoint - checks that a text string appears on a Web page.
      • Image Checkpoint - checks for an image on a Web page.
    • 46. How do I verify Web page content? Contd..
      • Text Checkpoint – Go to Tree View
      Right Click Click Here
    • 47. How do I verify Web page content? Contd..
      • Image Checkpoint – Go to Tree View
      Right Click Click Here
    • 48. Did my test succeed?
      • Playback the Script
      • Enable image checks.
      • Run the script.
      • Locate the text check.
      • Locate the image check.
    • 49. Creating a Load Testing Scenario
    • 50. Topics to be Covered
      • Introducing the LoadRunner Controller
      • What mixture of users should be part of the load test?
      • How do I generate a heavy load?
      • How do I emulate real load behavior?
      • How do I emulate different types of users?
    • 51. Introducing the LoadRunner Controller
      • Scenario Objective
      • The objective is to create a scenario that emulates the behavior of ten travel agents simultaneously logging on, searching flights, purchasing flights, checking itineraries, and logging off the system.
    • 52. Introducing the LoadRunner Controller Contd..
      • Starting the Controller
      • Open Mercury LoadRunner - Choose Start > Programs > Mercury LoadRunner > LoadRunner .
      • Open the Controller. - In the Load Testing tab, click Run Load Tests . The LoadRunner Controller opens.
      • Select a Scenario Type. – Manual or Goal Oriented Scenario
    • 53. What mixture of users should be part of the load test?
      • Eight users would be added simultaneously and two afterwards
      • Add a script to the load test.
      • Begin designing the load test scenario.
      • Change the Group Name and number of Vusers.
        • Click the Details button.
        • In the Vuser Quantity box, enter 8.
        • Click on OK.
    • 54. How do I generate a heavy load?
      • Add a load generator.
        • Click the Generators button and add the generator which can be used to apply load.
      • Test the load generator connection.
        • Select the localhost load generator and click Connect .
        • Click Close .
    • 55. How do I emulate real load behavior? Edit Schedule
      • Change the Scenario Schedule default settings.
      • Specify a gradual start. (Ramp Up)
      • Initialize the Vusers. (To minimize CPU consumption)
      • Schedule the duration.
      • Schedule a gradual closure.( Ramp Down)
      • View Graphical representation of the scheduler. Click OK
    • 56. How do I emulate different types of users? Set Runtime Settings
      • Open the Run-Time settings.
      • Enable think time.
      • Enable logging.
      • Browser Emulation
      • Content Check
      • Pacing
    • 57. Running The Load Test
    • 58. Topics to be Covered
      • The Controller Run View at a Glance
      • How do I run a load test scenario?
      • How do I monitor the application under load?
      • How can I increase the load during the test?
      • Did the application perform well under load?
    • 59. The Controller Run View at a Glance
    • 60. How do I run a load test scenario?
      • Open the Controller Run view.
      • Start the scenario.
          • Set the path of the result directory
          • Click on OK.
    • 61. How do I monitor the application under load?
      • Examine the Performance graphs.
          • Running Vusers - Whole Scenario
          • Transaction Response Time - Whole Scenario
          • Hits per Second - Whole Scenario
      • Highlight individual measurements.
          • Double click the graph to highlight the same
    • 62. How can I increase the load during the test?
      • Click the Vusers button. The Vusers window opens.
    • 63. Did the application perform well under load?
      • Visualize the Transaction Response Time and determine whether the transaction was within acceptable limit for the customer.
      • If the transaction response time degrades, look for bottlenecks.
    • 64. Analyzing Scenario
    • 65. Topics to be Covered
      • How does an analysis session work?
      • How do I start my analysis session?
      • The Analysis Window at a Glance
      • Did I reach my goals?
      • Did my server perform well?
      • How can I pinpoint the source of the problem?
      • How can I publish my findings?
    • 66. How does an analysis session work?
      • Were the test expectations met? What was the transaction response time on the user’s end under load? What was the average transaction response time of the transactions?
      • What parts of the system could have contributed to the decline in performance? What was the response time of the network and servers?
    • 67. How do I start my analysis session?
      • Open Mercury LoadRunner.
          • Choose Start > Programs > Mercury LoadRunner > LoadRunner .
      • Open LoadRunner Analysis.
          • In the Load Testing tab, click Analyze Load Tests .
      • Open the analysis session file.
          • File > Open .
          • From the <LoadRunner Installation> Tutorial folder, select analysis_session and click Open .
    • 68. The Analysis Window at a Glance
    • 69. Did I reach my goals?
      • Check Transaction Summary Area
    • 70. Did I reach my goals? Contd..
      • Check Transaction Summary Area
      • Open the Average Transaction Response Time graph.
              • Click the check_itinerary transaction, in the Transaction Name column.
    • 71. Did my server perform well?
      • Study the behavior of the Vusers.
              • Click Running Vusers in the graph tree.
      • Filter the graph so that you see only the time slice when all the Vusers ran simultaneously.
    • 72. Did my server perform well? Contd..
      • Correlate the Running Vusers and Average Transaction Response Time graphs to compare their data.
            • Right-click the Running Vusers graph and choose Merge Graphs .
            • From the Select graph to merge with list, choose Average Transaction
            • Response Time .
            • In the Select type of merge area, select Correlate , and click OK .
      • Analyze the correlated graph
    • 73. How can I pinpoint the source of the problem?
      • From the graph tree, select the Average Transaction Response Time graph.
      • Filter the Average Transaction Response Time graph to display only the check_itinerary transaction.
            • Right-click the graph, and choose Set Filter/Group by .
            • In the Transaction Name value box, select check_itinerary .
            • Click OK .
    • 74. How can I pinpoint the source of the problem? Contd..
      • Auto-correlate the graph.
            • Right-click the graph, and choose Auto Correlate . Click OK .
    • 75. How can I pinpoint the source of the problem? Contd..
      • Rename the graph.
        • Choose Rename Graph .
        • Type Auto Correlated - check_itinerary and press ENTER
      • Analyze the auto-correlated graph.
        • Look at the legend below the graph.
      • In the Measurement column you can see that the Private Bytes and Pool Nonpaged Bytes , both of which are memory-related measurements, have a Correlation Match of over 70% with the check_itinerary transaction.
    • 76. How can I publish my findings?
      • HTML Reports
      • From the Reports menu, choose HTML Report.. .
      • Select a file name for your report, and the path where you want to save it. Click Save .
    • 77. Thank You.

    ×