We will discuss correlation in a subsequent chapter. Review the list of ports. Connect the scripts to the test data. The active protocols being used in the script will be displayed here. You define transactions to measure the performance tutoroal your system. Once the System has been validated for its functionality during the System and Integration testing phase, performance testing is conducted. Correlation — Configuration This is the general configuration used by the rules once the recording is complete.
For such a case, navigate to Multiple Protocols list on the left side of window. This includes generating code, transactions, and comments based on your recording. This is not the case for HTML recording. VuGen works on the principle of record and playback. Performance testing can be broken tutoriak into the following categories.
He is the main stakeholder for any escalations. VuGen — The Loadeunner component is used to simulate the exact business transaction within your applications. Infrastructure team — Ensure the entire infrastructure team is place to monitor the servers for the application which is being tested. It is a good practice to analyze only one business process at a time since the various business process in a large enterprise application may involve various protocols.
Keep the first option as chosen and click on the Continue button. Usually, this is the first step of scripting where every user action is recorded into a script. The performance tests should be conducted against environments that are identical to production. Recording options in LoadRunner While recording, there are a variety of options available to the tester. Send your email to: If you have made changes to your script as per Step 2, then the script verification process is an important step.
In a real world scenario, always test the business scenarios to make sure they are working as they should, before you start the scripting process. The list looks slightly different from previous versions 1. VUGen will create one. Start a transaction by clicking button in floating bar. The Controller is used to manage these agents. How to insert Comments Comments can be inserted at any point during the recording session. Below is the normal process followed when developing any load testing script.
If someone changes the Web page and removes the phrase Find Flight, then in subsequent runs, the output will indicate that the text was not found. Locate the beginning of a transaction. Search for the word Transaction.
This notification is shown in blue. View the parameter substitution. Search for the word Parameter. Search again F3 for the next substitution. Note how VuGen takes a different value for each iteration. In this lesson, you will evaluate your system under the load of multiple Vusers. You will emulate the actions of ten travel agents concurrently using the flight reservation system, and observe the behavior of the system under the load of these users.
To design and run this test, you use the LoadRunner Controller. Scenario Objectives In this lesson, 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.
Introducing the LoadRunner Controller Load testing means testing your system under typical working conditions. For example, you may test the system while many travel agents simultaneously reserve flights on the same flight reservation system. You design the test to emulate real-life situations. To do this, you need to be able to generate a load on an application and schedule when the load is applied because users do not log on and off the system at precisely the same time.
You also need to emulate different types of user activity and behavior. For example, some users may use Firefox to access the system, whereas other users use Internet Explorer. Users may also employ different network connections to access the system, such as modem, DSL, or cable.
You create and save these settings in a scenario. The Controller provides you with all the tools you need to help you build and run tests to accurately emulate your working environment. How do I start the Controller? To begin developing a scenario, you open the LoadRunner Controller.
Select a scenario type. There are two scenario types: A Manual Scenario gives you control over the number of running Vusers and the times at which they run, and lets you test how many Vusers your application can run simultaneously.
You can use Percentage Mode to distribute the total number of Vusers between the scripts based on a percentage specified by your business analyst. The Percentage Mode check box is selected by default the first time you start LoadRunner following installation.
If it is selected, clear it. A Goal-Oriented Scenario is used to determine if your system can achieve a particular goal. Add a Vuser script to the load test. In this tutorial, you will use only one Vuser script to model a single group of users performing identical actions. To more accurately emulate a real-world scenario with more versatile user profiles, you would create a number of different Vuser groups, with each group running several scripts with different user settings.
The script that you previously recorded in VuGen contains the business processes that you want to test. They include logging on, searching for a flight, buying a ticket, checking the flight itinerary, and then logging off the site. You will add a similar script to the scenario, and configure the scenario to emulate eight travel agents simultaneously performing these actions on the flight reservation system. You will add two more Vusers during the test.
For this purpose, a sample script is provided that is similar to the one you created. We recommend that you use the sample script. In the New Scenario dialog box, click the Browse button. Click Open. The LoadRunner Controller opens and displays the Design tab of your new scenario. Note that the control for the Design tab is in the lower left corner of the Controller. The Controller at a Glance The Design tab of the Controller is the main interface for designing your load test.
Scenario Groups pane 2. Service Level Agreement pane 3. Scenario Schedule pane 1. Scenario Groups pane. You configure the Vuser groups in the Scenario Scripts pane. You create different groups to represent typical users of your system and specify the number of Vusers that will run, and the machine that they will run on.
Service Level Agreement pane. When you design a load test scenario, you can define goals or SLAs Service Level Agreements for the performance metrics. When you run the scenario, LoadRunner gathers and stores performance-related data. Scenario Schedule pane. In the Scenario Schedule pane, you set the load behavior to accurately portray real-world user behavior.
You define actions according to which the Vusers will run, the rates at which load is applied to the application, the load test duration, and how the load is terminated. How do I modify the script details? You modify the script details as follows: 1. Change the Group Name. The Group Information dialog box opens. The new name is displayed in the Scenario Groups pane of the Design tab. How do I generate a load on the system? After you have added your Vuser scripts to the scenario, you configure the load generators, the computers that generate the load on the system.
A load generator is a computer that runs multiple Vusers in order to generate a load on the system. You can use a number of load generators, each generator hosting multiple Vusers. In this section, you will learn about adding load generators to the scenario, and testing the load generator connections.
Add a load generator. Click the Load Generators button on the Controller toolbar. The Load Generators dialog box opens. The Load Generators dialog box shows details for the load generator called localhost. The status of the localhost load generator is Down. This indicates that the Controller is not connected to the localhost load generator. In this tutorial, you will use your local computer as the load generator.
Note that in a typical operational system, you would have several load generators, each hosting multiple Vusers. Test the load generator connection. When you run a scenario, the Controller connects to the load generators automatically. However, you can test the connections before trying to run the scenario.
In the Load Generators dialog box, select localhost and click Connect. The Controller attempts to connect to the load generator machine. When a connection has been made, the Status of the load generator changes from Down to Ready. Click Close. How do I emulate real load behavior? After you have added your load generators, you are ready to configure load behavior. LoadRunner allows users to gradually log on to and off the system.
It also lets you determine the duration of the scenario, and the way in which the scenario terminates. The scenario that you will configure below will be relatively simple.
However, when designing a scenario that more accurately reflects a real life scenario, you can define more true-to-life Vuser activity. You configure the load behavior for a manual scenario in the Scenario Schedule pane of the Controller. The Scenario Schedule pane is divided into three sections: the Schedule Definition area, the Actions grid, and the Interactive Schedule graph. You will now change the default load settings and configure a scenario schedule.
Select schedule type and run mode. Set the scheduled action definitions. You can set the Start Vusers, Duration, and Stop Vusers actions for the scenario schedules from either the Global Schedule grid, or by manipulating the Interactive Schedule graph. When you set the definitions from the graph, the Global Schedule grid properties adjust accordingly.
You will now set the definitions so that the Global Schedule grid will look as below. Set up the Vuser Initialization. Depending on your system configuration, initializing Vusers before they start running may provide more realistic results. Double-click Initialize in the Global Schedule grid. The Edit Action dialog box opens displaying the Initialize action.
Select Initialize all Vusers simultaneously. Specify a gradual start for the Vusers Starting Vusers at intervals allows you to examine the gradual increase of Vuser load on the application under test over time, and helps you pinpoint exactly when the system response time slows down.
Double-click Start Vusers in the Global Schedulegrid. The Edit Action dialog box opens displaying the Start Vusers action. In the Start X Vusers box, enter 8, and select the second option— 2 Vusers every 30 seconds. Schedule the duration. You specify a duration to make sure that the Vusers continue performing the schedule action for a specific period so you can measure continuous load on the server.
In the Interactive Schedule Graph, click the horizontal line which represents Duration. The line is highlighted and a dot and a diamond are displayed at its endpoints. Note that if the Legend is displayed on top of the diamond, click the Hide Legend button on the Interactive Schedule Graph toolbar to show the diamond.
Drag the diamond shaped endpoint to the right until the time in brackets reads You have just set the Vusers to run for a period of 10 minutes. Schedule a gradual closure. Gradually stopping Vusers is recommended to help detect memory leaks and check system recovery, after the application has reached a threshold. Double-click Stop Vusers in the Global Schedule grid. The Edit Action dialog box opens displaying the Stop Vusers action. Select the second option and enter the following values—2 Vusers every 30 seconds.
How do I emulate different types of users? Now that you have configured a load schedule, you will specify how the Vusers will behave during the test. Behavior refers to the time that a user takes to pause between actions, the number of times a user repeats an action, and so on.
Open the run-time settings. In the Controller, click the Design tab. The Run-Time Settings dialog box opens. The run-time settings let you emulate different kinds of user activity and behavior.
They include: Run Logic. The number of times a Vuser repeats a set of actions. The time to wait before repeating the action. The level of information that you want to gather during the test.
The first time you run a scenario, it is recommended to generate log messages to make sure that you have debugging information in case the first run fails. Think Time. The time the user stops to think between steps. Since users interact with the application according to their experience level and objectives, more technically proficient users may work more quickly than new users. Vusers can be made to emulate their real- world counterparts more accurately during a load test by enabling think time.
Speed Simulation. Users using different network connections such as modem, DSL, and cable. Browser Emulation. Content Check. For automatically detecting user-defined errors. This custom page always contains the words ASP Error. You need to search all of the pages returned by the server and see if the text ASP Error appears. You can set up LoadRunner to automatically look for this text during the test run, using the Content Check run-time settings. LoadRunner searches for the text and generates an error if it is detected.
During the scenario run, you can identify the content check errors. Enable think time. Select Replay think time, and select Use random percentage of recorded think time.
The above specifications use a random percentage of the recorded think time to emulate users with a varying range of proficiency. Enable logging. Select Enable logging. Under Log options, select Always send messages. Click Extended log, and select Data returned by server.
It is enabled only for the purposes of this tutorial to provide information for the Vuser Output log. Save the scenario. How do I monitor the system under load? Now that you have defined how your Vusers will behave during the test, you are ready to set up your monitors.
While generating a load on an application, you want to see how the application performs in real time and where potential bottlenecks exist. For instance, you can select a Web Server Resources monitor according to the type of Web server that is running. You can purchase a license for the relevant monitor, for example IIS, and use that monitor to pinpoint problems reflected in the IIS resources.
In this section, you will learn how to add and configure the Windows Resources monitor. You can use this monitor to determine the impact of load on your CPU, disk, and memory resources.
Select the Windows Resources Monitor. Click the Run tab at the bottom of the Controller. The Windows Resources graph is one of four default graphs that are displayed in the graph viewing area. You will learn how to open other graphs in the next lesson. Right-click inside the Windows Resources graph and select Add Measurements. The Windows Resources dialog box opens. Select the monitored server. The Add Machine dialog box opens. In the Name box, type localhost. If your load generator was running off a different machine you would type the server name or IP address of that machine.
From the Platform list, select the platform on which the machine runs. Activate the monitor. In this lesson you will cover the following topics: l The Controller Run view at a glance l How do I run a load test scenario? The Controller Run view at a glance The Run tab in the Controller is the control center from which the scenario is managed and monitored. The Run tab located at the lower section of the Controller window contains five panes: 1. In the upper-left pane, you can view the status of Vusers in the scenario groups.
You use the buttons to the right of this pane to start, stop, and reset the scenario, to view individual Vuser status, and to increase the load on the application during a scenario by manually adding more Vusers. Scenario Status pane. In the upper-right pane, you can view a summary of the load test, including the number of running Vusers and the status of each Vuser action.
Available Graphs pane. In the middle-left pane, you can see a list of the LoadRunner graphs. To open a graph, select a graph in the tree, and drag it into the graph viewing area. Graph Display pane. Graph Legend pane. In the bottom pane, you can view data from the selected graph. Note that the control for the Run tab is at the bottom of the Controller. In this section, you will start the scenario. Open the Controller Run view.
Notice that there are 8 Vusers in the Down column of the Scenario Groups pane. These are the Vusers you created when you created the scenario. Since the scenario has not yet run, all other counters remain at zero and all the graphs in the graph viewing area except Windows Resources are blank. When you start running the scenario in the next step, the graphs and counters will begin to display information.
Start the scenario. If you are running the tutorial for the first time, the Controller begins the scenario. If you are repeating the test, you will be prompted to overwrite the existing results file. Click No, because the results of the first load test should be used as baseline results to be compared with subsequent load test results. The Set Results Directory dialog box opens. Enter a unique and meaningful name for each results set, because you may want to superimpose the results of several scenario runs when you come to analyze the graphs.
How do I monitor the application under load? You use this information to isolate potential problem areas in your system environment. Examine the performance graphs. The Graph Display pane of the Run tab displays the following default graphs: a. Running Vusers - Whole Scenario graph.
Displays the number of Vusers running at a given time. Transaction Response Time - Whole Scenario graph. Shows the amount of time it takes for each transaction to be completed.
Hits per Second - Whole Scenario graph. Windows Resources graph. Highlight individual measurements. Double-click the Windows Resources graph to enlarge it to fit the entire Graph Display pane.
Notice that each measurement appears on a color-coded row in the Graph Legend pane. Each row corresponds to a line in the graph with the same color. Select a row to highlight the corresponding line in the graph, and vice versa. Double-click the graph again to reduce its size. View the throughput information. The Throughput graph shows the amount of data measured in bytes that the Vusers receive from the server in any given second.
You can compare this graph with the Transaction Response Time graph to see how throughput affects transaction performance. If the throughput scales upward as time progresses and the number of Vusers increases, this indicates that the bandwidth is sufficient.
If the graph were to remain relatively flat as the number of Vusers increased, it would be reasonable to conclude that the bandwidth is constraining the volume of data delivered. When emulating users, you should be able to view the Vusers' actions in real time to make sure they are performing the correct actions. The Controller lets you view the actions in real time using the Run-Time Viewer. In the Controller's Run tab, click the Vusers button. The Vusers dialog box opens. The Status column displays the status of each Vuser.
In the example above, you can see that four Vusers are running and four are down. The Start Vusers action in the scheduler instructed the Controller to release two Vusers at a time. As the scenario progresses, Vusers will continue to be added in groups of two at second intervals. Select a running Vuser in the Vuser list. Click the Show the selected Vusers button on the Vusers toolbar. The Run-Time Viewer opens and displays the actions performed by the selected Vuser. Where can I view a summary of Vuser actions?
In the Vusers window, select a running Vuser. Click the Show Vuser Log button on the Vusers toolbar. The Vuser log dialog box opens. The log contains messages that correspond to the actions of the Vuser. For example, in the window above, the message Virtual User Script started indicates the start of the Vuser's run. Scroll to the bottom of the log and watch as new messages are added for each action performed by the Vuser. Close the Vuser Log dialog box and the Vusers dialog box.
How can I increase the load during the test? You can manually add more Vusers during a load test to increase the load on the system. To increase the load during a load test: a. Make sure that in the Controller, the Run tab is displayed b. In the column, enter the number of Vusers that you want to add to the group.
To run two additional Vusers, replace the number 8 with the number 2, in the column. Click Run to add the Vusers. If some of the original Vusers have not yet been initialized, the Run Initialized and Run New options appear. Select the Run New option. The Scenario Status pane shows that there are now 10 running Vusers. You may get a warning message that the LoadRunner Controller cannot activate additional Vusers.
This is because you are using your local machine as a load generator and it has limited memory resources. Generally, use a dedicated machine as a load generator to avoid this issue. How is the application performing under load? Check the Scenario Status pane [on the Run tab] for a summary of the running scenario. In the Scenario Status pane, you can drill down to see which Vuser actions are causing the application problems.
A high number of failed transactions and errors may indicate that the application is not performing as required under load. View the scenario status. The header of the Scenario Status pane displays the overall status of the scenario. View a breakdown of Vuser actions. Click Passed Transactions in the Scenario Status pane. The Transactions dialog box opens and displays a list of transaction details. Click Close to close the Transactions dialog box.
Did the application encounter errors? If an application starts to fail under heavy load, you are likely to encounter errors and failed transactions. The Controller displays error messages in the Output window. Check for any error or warning messages. You can sort the message by type, such as Warnings or Errors.
The Output dialog box opens and lists a message text, the total number of messages generated, the Vusers and load generators that generated the error, and the scripts in which the errors occurred. To view a message in detail, select the message and click Details. The Detailed Message Text box opens, displaying the complete message text. View log information details. You can view information about each message, Vuser, script, and load generator associated with an error code by clicking the blue link in the appropriate column.
For example, to locate where in the script an error occurred, drill down the Total Messages column. The Output window displays a list of all messages of the selected error code, including the time, iteration number, and line in the script where the error occurred.
Drill down the Line Number column. VuGen opens, displaying the line in the script at which the error occurred. You can use this information to identify transactions with slow response times that are causing the application to fail under load. How do I know that the scenario has finished running? At the conclusion of a scenario run, the header of the Scenario Status pane shows the Down status. This indicates that all the Vusers in the scenario have finished running. The Vuser dialog box displays the number of iterations that each Vuser performed, the number of successful iterations, and the elapsed time.
Did the system perform well under load? To see how well the system performed under load, look at the transaction response times and determine whether the response times were within acceptable limits.
If the transaction response times increase during the scenario, you need to look for bottlenecks. You will learn more about this in "Lesson 7: Analyzing Your Scenario" on page Once a problem has been isolated, a corroborative effort involving developers, DBAs, network, and other systems experts is required to fix the problem.
After adjustments are made, the load test is repeated to confirm that the adjustments had the desired effect. You repeat this cycle to optimize system performance. Once you have loaded your server, you want to analyze the run, and pinpoint the problems that need to be eliminated to improve system performance.
The graphs and reports produced during your analysis session present important information about the performance of your scenario.
Using these graphs and reports, you can pinpoint and identify the bottlenecks in your application, and determine what changes need to be made to your system to improve its performance. In this lesson, you will cover the following topics: l How does an analysis session work? Service Level Agreement l How do I view a summary of performance? Did the SLA meet or deviate from its goals? What was the average transaction time of the transactions? What was the time of the network and servers?
In the following sections, you will learn how to open LoadRunner Analysis, and build and view graphs and reports that will help you find performance problems and pinpoint the sources of these problems. HP LoadRunner Analysis opens. Open the analysis session file. For the purpose of this section in the tutorial, in order to illustrate more diverse results, we ran a scenario similar to those you ran in the previous lessons.
This time, however, the scenario incorporated 70 Vusers rather than 10 Vusers. You will now open the analysis session created from the results of this scenario. The Open Analysis Session dialog box opens. Analysis opens the session file. The Analysis window at a glance Analysis contains the following primary panes: 1. Session Explorer 2. Properties pane 3. Legend pane 1. Session Explorer. In the upper left pane, Analysis shows the reports and graphs that are open for viewing.
From here you can display new reports or graphs that do not appear when Analysis opens, or delete ones that you no longer want to view. Properties pane. In the lower left pane, the Properties pane displays the details of the graph or report you selected in the Session Explorer. Fields that appear in black are editable. Graph Viewing pane. In the upper right pane, Analysis displays the graphs. By default, the Summary Report is displayed in this area when you open a session.
Legend pane. In the lower right pane, you can view data from the selected graph. Note: There are additional panes that can be accessed from the toolbar. These panes can be dragged and dropped anywhere on the screen. Did I reach my goals? SLAs are specific goals that you define for your load test scenario. Analysis compares these goals against performance-related data that LoadRunner gathers and stores during the run, and then determines the SLA status Pass or Fail for the goal.
After the test run ends, LoadRunner compares the goals you defined against the actual recorded average transaction times. For example, if the actual average transaction time did not exceed the threshold you defined, the SLA status will be Pass.
As part of your goal definition, you can instruct the SLA to take load criteria into account. This means that the acceptable threshold will vary depending on the level of load, for example, Running Vusers, Throughput, and so on. As the load increases, you can allow a higher threshold.
Depending on your defined goal, LoadRunner determines SLA statuses in one of the following ways: l SLA status determined at time intervals over a timeline. Analysis displays SLA statuses at set time intervals for example, every 5 seconds over a timeline within the run. Analysis displays a single SLA status for the whole scenario run.
SLAs can be defined either before running a scenario in the Controller, or after in Analysis itself. To do this, you select the transactions and then set threshold values. These threshold values are the maximum amounts of time that would be acceptable as average transaction times. You will also set these threshold values to take certain load criteria into account; in this case Running Vusers. In other words, as the number of running Vusers increases, the threshold value rises.
This is because although the HP Web Tours administrator would like the average transaction times to be as low as possible, it is understood that at certain times of the year it is reasonable to assume that the HP Web Tours site will have to handle a higher load than at other times of the year.
For example, during peak travel season, a higher number of travel agents log on to the site to book flights, check itineraries, and so on. Given this understandably higher load, at these times a slightly longer average transaction time will be acceptable.
You will set the SLA to take three load scenarios into account: light load, average load, and heavy load. Each scenario will have its own threshold value. How do I define an SLA? You will define an SLA in Analysis after the scenario run.
However, for the purposes of this tutorial, because you are not analyzing the same test scenario that you ran in previous lessons, you will define the SLA in Analysis. The average transaction times will be measured at set time intervals within the run.
Open the SLA wizard. The Service Level Agreement dialog box opens. Click New to open the Service Level Agreement wizard. Note that the first time you open the Service Level Agreement wizard, the Start page is displayed. Click Next. Select a measurement for your goal. Select the transactions to monitor. In the Select Transactions page, select a transaction to monitor from the Available Transactions list.
Set the load criteria. Select Running Vusers from the Load Criteria drop down list. Between 0 and 19 Vusers - Average load.
Between 20 and 49 Vusers - Heavy load. More than 50 Vusers c. Set threshold values. Save the SLA. The report is then updated to include all the relevant SLA information. How do I view a summary of performance? The Summary Report tab displays general information and statistics about the scenario run, as well as all relevant SLA information. For example, what were the worst performing transactions in terms of defined SLAs, how specific transactions performed over set time intervals, and overall SLA statuses.
You open the Summary Report from the Session Explorer. What are the overall scenario statistics? In the Statistics Summary section, you can see that a maximum of 70 Vusers ran in this test. What were the worst performing transactions?
The 5 Worst Transactions table shows you up to five worst-performing transactions for which SLAs were defined. The average percentage by which it exceeded the SLA threshold over the whole run was Over which time intervals was the SLA threshold exceeded? The Scenario Behavior Over Time section shows how each transaction performed during different time intervals. The green squares show time intervals where the transaction performed within the SLA threshold, red squares where the transaction failed, and gray squares where no relevant SLA was defined.
What was the overall transaction performance? The Transaction Summary lists a summary of the behavior of each transaction. Review the times of each transaction. This is double its average time, How do I graphically view performance? You can access available graphs from the Session Explorer pane. You will now view and analyze the Average Transaction Response Time graph.
Open the Average Transaction Response Time graph. The Average Transaction Response Time graph opens in the graph viewing area. Click Open Graph to add the graph to the Session Explorer pane.
The points on the graph represent the average time of a transaction at a specific time during the scenario. Hold your cursor over a point in the graph. A yellow box appears, and displays the coordinates of that point.
Analyze the results. Did my server perform well? Study the behavior of the Vusers. The Running Vusers graph opens in the graph viewing area. You can see that there was a gradual start of running Vusers at the beginning of the scenario run.
Then, for a period of 3 minutes, 70 Vusers ran simultaneously, after which the Vusers gradually stopped running. Filter the graph so that you see only the time slice when all the Vusers ran simultaneously. When you filter a graph, the graph data is narrowed down so that only the data for the condition that you specified is displayed.
All other data is hidden. Click the down-arrow and specify a time range from minutes to minutes. In the Graph Settings dialog box, click OK. All other Vusers have been filtered out. This is called correlating two graphs.
For example, you can correlate the Running Vusers graph with the Average Transaction Response Time graph to see the effect of a large number of Vusers on the average time of the transactions. Right-click the graph and select Merge Graphs. Under Select type of merge, select Correlate, and click OK.
Analyze the correlated graph. In other words, the average time increases as the load increases. At 66 Vusers, there is a sudden, sharp increase in the average time. We say that the test broke the server. The time clearly began to degrade when there were more than 66 Vusers running simultaneously.
Saving a template So far you have filtered a graph and correlated two graphs. The next time you analyze a scenario, you might want to view the same graphs, with the same filter and merge conditions applied. You can save your merge and filter settings into a template, and apply them in another analysis session. To save your template: 1. In the Templates pane, click the New button. The Add New Template dialog box opens. Enter an appropriate name for the template and click OK.
The next time you open a new analysis session and want to use a saved template: 1. Select your template from the list, and click Save and close. How can I pinpoint the source of the problem? From the graph tree, select the Average Transaction Response Time graph. The average response time started to increase almost immediately, until it peaked at nearly 3 minutes. Auto-correlate the graph. Right-click the graph, and select Auto Correlate.
The auto-correlated graph opens in the graph viewing area. Rename the graph. The graph name becomes editable. Analyze the auto-correlated graph. In addition to the graphs that appear in the graph tree at the start of an analysis session, you can display different graphs to get other information about your scenario run. The Open a New Graph dialog box opens and lists the categories of graphs that contain data and can be displayed.
Displays information about the Vusers and their status. Displays error statistics. Displays data about transactions and their response times.
0コメント