Performance Testing

Performance Testing - Load Runner

Performance testing is to check for the robustness of the application.

Objectives of the performance testing are:

· Check whether application can sustain real world/expected load.

· To find the breaking crash point of an application.

· To identify performance bottlenecks

· Capacity planning

· Configuration sizing.

· Regression

Capacity planning is the planning done when the load goes beyond expected load to upgrade the servers so that the application can sustain more number of users.

Configuration sizing is checking the application with mix of hardware, software and network configuration.

Regression is adding, deleting the features existing in the current application, and to identify if that results in any performance degradation.

Types of performance testing

Load testing: To find out whether an application can sustain real world/expected load. Testing is done at peak time/peak load. During load testing the following is considered;

· Load <= expected load.

· Ramp up/ramp down duration procedure is followed.

Stress or overload or over drive testing:

Objective is to find out crash or braking or upper limit of an application.

Increasing the load >= expected load.

Ramp up here is done in smaller steps compared to load testing.

Soak testing (Endurance Testing)

Performing load testing for longer duration. Similar to load testing but the duration is longer.

Fail over testing:

When one of the server components fails the load balancer should be able to take back the load given on the route that is blocked and redistribute it among other active routes and make sure client request is processed.

DB servers are synchronized. Not done by performance team.

Fail back testing:

The server component that failed if it is service after some time, load balance should take the extra load that was given on the other server and send this request on the service route and make sure client requests are processed.

Load balancer is software which equally divides load among available active servers.

Stages is load testing

Scoping à Prepare à Create scripts à Create scenario à Execute scenario à Analyze results à tweak the system based on the analysis---------------------------|

Scoping is gathering and understanding the requirements. These are performance requirements.

Prepare is preparing the performance plan.

Create scripts using Vugen (record and replay tool) i.e. virtual user generator. Tasks are created using vugen.

Create scenarios involves creating virtual users and assigning created tasks to virtual users and schedule the time for test execution.

Execute: Virtual users starts executing. Set monitors when executing. Virtual users are created by controller. Create and execution of scenario is done by using LR components called controller

Analyze results: When tasks are executed results are sent to analyzer.

Set SLA, Compare actual results with SLA, Generate reports and graphs, Hand over to team who analyze the results.

Software tuning is done by development team.

DB testing done by DB team.

Network tuning done by network team.

Hardware tuning is done system administration team.

Components of Load runner:

· Vugen

· Controller

· Analyzer

When installed vugen and analyzer comes along. Controller requires license.

Steps in load testing:

Scoping -> Prepare -> Create Scripts -> Create Scenarios -> Execute Scenarios -> Analyze results -> Tweak the system based on analysis ---------------------------|

Scoping is gathering and understanding the requirements. These are performance requirements.

Prepare is test planning.

Create scripts: Use VUgen (record and replay tool) i.e. virtual user generator. Tasks are created using vugen.

Create Scenario: Create virtual user and assign created tasks virtual users and schedule the time for execution.

Execute scenarios: VU’s starts executing. Set monitors when executing.

VU’s re created by controllers.

Create and execution of scenario’s are done by using LR components called as controller.

Analyze results: When tasks are executed, results are sent to analyzer.

Set SLA -> Compare actual results with SLA -> Generate reports and graphs -> Hand over to the team to analyze.

Components of LR:

Vugen, Controller and Analyzer.

Vugen and analyzer come when LR is installed. Controller has license.

Vugen is a record and play tool. Vugen is a single user environment.

Vugen:

· Needs access to controller.

· Needs access to AUT.

· Supports single user execution.

· Scripts created in vugen has .usr extension.

· Can be installed in windows.

Controller:

· Used to create and execute scenarios

· Needs access to Load Generator, Analyzer and monitor.

· Supports multiuser environment.

· Needs license

· Scenarios created in controller has .lrs extension.

· Results stored in controller has .lrr extension.

· Can be installed only in windows OS.

Load Generator:

Machines used by vusers to perform tasks on AUT.

LR Architecture

Vugen:

· Tool used to create scripts.

· Needs access to controller.

· Needs access to AUT

· Supports single user application.

· Free to use

· Scripts create in Vugen has .usr extension.

· Can be installed in windows

Controller:

· Used to create and execute scenario and monitor scenario.

· Needs access to analyzer, load generator, monitor and AUT.

· Supports multiuser execution.

· Needs license.

· Scenario created in controller has .lrs extension

· Can only be installed in windows OS.

Load Generator:

· Machine/s used by vusers to perform tasks on UAT.

· LG has access to controller and AUT.

· LG supports both windows and unix.

Analyzer:

· Used to set SLA, compare actual results with SLA and generate reports.

· Free of cost.

· Supports only windows platform.

Scoping involves gathering of system usage information. It involves

· Understanding application

· First hand knowledge to be obtained by using the application

· Visit competitor’s website and understand the standards available in the market.

· Consult system architecture to understand the architecture.

· Consult SME to understand the application.

· Identify business process and understand logical steps to achieve and set goals.

· Classify business process into three steps:

o Misson critical bp – main objective is why the application is used. Ex – Booking flight.

o Heavy thro put bp – Web pages subjected to heavy usage. Ex – Login/Logout

o Dynamic content bp – Web pages generated by server during runtime which is uniqe for every execution. Ex: Confirmation page.

Workload model gives information about the different business process that we can run on application and gives information about peak load and peak load time on an application under test.

Analyze system under test:

· Know the system architecture or application architecture

· Map business process to system components.

· Make sure the server components are up and running.

Steps in VUGen:

Start à Select Protocol à Set start record window àSet recording options àStart recording à Stop recording à Edit runtime settings àEnhance scripts à Compile and run scripts àView last replay summary àView test results à Stop.

Vuser à Start recording à Ctrl R.

Vuser à Runtime settings à F4

Tools à Recording Options à Ctrl F7

Protocol is the language used by client to communicate with server.

Client uses TCP/IP protocol to communicate with server.

Request is sent thro HTTP protocol.

First step is vugen is to select the protocol.

When clicked on OK in the above, it takes to the below start recording screen;

URL of the web site should be entered in the URL Address.

Runtime settings – F4

General

Runlogic - Iterations

Pacing – Start new iterations

Log – Enable logging, standard log, extended log.

Think time – Replay/Ignore Think Time

Additional Attributes

Miscellaneous – Multithreading, Run Vuser as a thread.

Network

Speed Simulation

Browser

Browser Emulation – Simulate browser cache, Simulate new user on each iteration

Internet Protocol

Proxy

Preferences – Enable image and text check

Download filters

Content check – Enable content check during replay.

Recording Options – Ctrl + F7

General

Script – Scripting language, scripting options.

Protocols

Recording – HTML based script/URL based script

Network

Port Mapping.

HTTP Properties

Advanced

Correlation

Insert -> Start Transaction, Ctrl + T

Insert -> End Transaction, Ctrl + D

Vuser -> Start Recording, Ctrl + R

Compile Script – Shift + F5

When clicked on start recording, a file called recording log is created. This recording log captures communication between client and server.

When clicked on stop recording, a file called generation log is created. This file is useful in identifying the left and right boundary of a dynamic value.

Run logic is how to run the scripts.

Run logic option is used to set iterations to action block. Iterations are set in runtime settings window in Runlogic.

Note:

Before recording an application vugen refers to recording option settings.

Before running the script vugen refers to runtime settings.

In vugen, we have three blocks

Vuser init

Action

Vuser end

Vuser init and vuser end run’s only once.

Action block supports iteration. Repeating a task more than once can be done in action block.

Recording Options:

Recording options can be set in the below screen, invoked by:

Tools à Recording Options or Ctrl F7.

By selecting script option we can select the language and the properties.

Protocol is helps us to select the protocol using which client interacts with the server.

There are two types of scripts:

HTML scripts are:

· High level context sensitive recording.

· Scripts generated are simple

· Modifying scripts is easier.

· Less time to execute.

· Suitable for internet applications.

URL scripts are:

· Low level analyzer recording

· Scripts generated is complex.

· Modifying scripts are complex.

· More time to execute.

· Suitable for non browser applications.

Resources are of two types:

HTML resources – text fields, buttons, checkbox, links etc

Non HTML resources – image, video, audio etc.

HTML mode requests functions for action performed by a user.

URL mode generates separate request function for each resource available in the web page.

When clicked on start recording a file called recording log is created. This captures communication between client and server at low level.

When clicked on stop recording a file called generation log is created. This log file is useful in identifying the left and right boundary of dynamic values.

To open run time settings:

Vuser à Run time settings or F4

Run logic is how to run the scripts. Runlogic option is used to set iterations to action block. Iterations are set in run time settings window à run logic.

Note:

Before recording an application vugen refers to recording option settings.

Before running the script vugen refers to runtime settings.

Pacing is the time gap between iterations.

Think time is the time gap between two consecutive requests. Or time spent on the web page before sending the requests.

Enhancing scripts include adding correlation, parameterization, transactions, content checks, user defined logic.

Compile and run scripts:

When we run the scripts a file called replay log is created. This file generation depends on the log settings done in the runtime settings window.

Replay log is helpful to understand if a script has run without errors.

Recording log, generation log and replay log can be find in output window.

Click on View à Output window to see output window.

To see view last replay summary, go to tasks and click on replay summary.

The last check box statement in the below tracks the activity of the machine.

So uncheck that option.

When clicked on start recording, floating tool bar opens up. Events gets recorded in the floating tool bar and wait till the events are constant or when web page says done.

Scripts generated can be viewed in two views:

· Script view – shows in terms of C functions.

· Tree view – shows in terms of steps.

In load runner there are two types of functions:

Protocol specific or request function: All the requests made by client during recording will be captured as request functions in script view.

All web_< > functions are protocol specific functions or request functions.

Example: web_url(), web_submit_form, web_image().

Load runner functions: Starts with lr_< > as prefix.

Web_url() is a function that launches an application specified in the url attribute in the URL address in start recording window.

Web_submit_form() submits a form which contains values for data fields within a web page.

Web_image() – whenever user clicks on an image, it generates a function called web_image. Every image is identified by two values – alternate name and image source name.

Lr_think_time(seconds) is the function for think time.

Last replay summary shows recording and replay snapshots.

To view test results, View à Test results.

First table gives the iteration details and second iteration gives the step details.

To filter test results window press Ctrl T or View à filters.

Filter can be done by:

· Iteration.

· Step status

· Content – Action steps are not shown if show only actions.

Pacing by random takes value between min and max value.

Third option – @ fixed intervals every…..

If i1 is 8 seconds and i2 is at 5 seconds, then pacing is ignored.

When fixed < iteration execution time, pacing is ignored.

When i1 > i2 the difference is considered.

Think time:

Use random percentage of recorded think time.

Think time is between requests.

Pacing is between iterations.

Correlation:

Session is the key generated by the server which is unique for every execution and it is generated during runtime. This key is required for the client to successfully login to the application. Session ids are time bound and is valid until user logs out of the application.

Whenever client submits data to the server for validation, if dynamic data is part of submission, LR uses a function call web_submit_data which is similar to web­_submit_form.

Vugen tool works based on response from the servers. If server response to a request the step would be passed. If no response, the step would be failed. By default tool does not look for the content of the page.

Correlation is the process of making a script to pass which failed due to dynamic values.

Web_reg_save_param(“parameter name”, “LB=SID=<”, RB=>”, “ORD=1”, LAST);

Search functions are called as registry functions. Functions with reg_ are called as registry functions.

Registry functions should always be inserted before the step where we need to do an operation.

Way of correlating a function:

After recording

· Automatic correlation.

· Manual correlation

Before recording

· Creating a correlation rule.

Automatic correlation:

· When a script fails due to dynamic values, go to Vuser menu àscan scripts for correlation of Ctrl + F8.

· The difference found between the response body of the recording and response body of replay will be shown in the output window à correlation results.

· Select he difference and click on correlation.

Manual correlation:

· Whenever a script fails, save the script and record one more script similar to the same script.

· Go to tools menu à compare with scripts and select save scripts for comparison.

· WDIFF utility of vugen compares both the scripts and report the deviation found between scripts highlighted in yellow color.

· From here know the name of the dynamic value.

· Now go to generation log and identify left and right boundary of a dynamic value by searching for the name of the dynamic value.

· Now go to tree view, select the steps that appear before the step where client is sending the dynamic value to the server for validation. Expand the server response of the step manually and search for dynamic value.

· If found go to scripts view and place the cursor before the step of function where server sent dynamic value and type the correlation function.

· Replace hard coded value in your script with the parameter defined in correlation function enclosed with in flower brackets.

Tree structure when a script is saved;

Before recording create a correlation rule.

Go to Ctrl F& à recording options à Correlation à check “enable correlation during recording”.

If application is not in the list click on new application and enter “web tours”

Click on new rule à to add a rule and give left, right boundary and ordinal.

Web_set_max_html_parame_len(1024) is the function inserted when a correlation rule is created before recording.

To create a correlation rule after recording:

Go to Vuser à scan script for correlation.

This rule is created under correlation studio rules.

Correlation rules that we create applies for scripts that we record after creating the rule.

Content checks:

We add certain function to check for content on a web page. The content can be either text or image in a web page.

If the content is found, the step would be passed and if not the step would be failed. This is done to check if we are in the right page with right content.

Text check:

During recording – web_reg_find().

After recording –

Web_find()

Web_reg_find().

Image check:

After recording – web_image_check().

Web_reg_find(“Text=JOJO”,

“search=body”

LAST);

Web_reg_find() should be placed above web_submit_form().

When search is not specified, it searches in header and body.

Web_find(“abc”,

“Left off=,”

“right off=welcome”,

“what=JOJO”

LAST);

Web_find() a non registry function and also all registry function should be placed after web_submit_form().

When ever web_find() is used to check text and image, go to F4 à runtime settings à Preferencesà and check “enable image and text check”

Image check

Web_image_check(“step name”,

“alt=”,

“source=”,

LAST);

To see response body goto: Tree view à submit forms à body à webtours à references… gives ALT and SRC properties of the image.

Image check can be added only after recording.

Transactions: are inserted in the scripts to check how much time server takes to send a response for a client request. It is used to gauge the performance of the servers.

Lr_start_transaction(“transaction name”)

Lr_end_transaction(“transaction name”, LR_AUTO);

Example:

Lr_start_transaction(“home page”)

Web_url()

Le_end_transaction(“home page”, LR_AUTO);

Lr_start_transaction(“user page”)

Web_submit_form()

Le_end_transaction(“user page”, LR_AUTO);

Lr_start_transaction(“logged off”)

Web_image()

Le_end_transaction(“logged off”, LR_AUTO);

During transaction think time should always be outside transaction.

After recording:

Insert menu à start transaction – give transaction name.

Insert menu à end transaction – give transaction name.

Registry and non registry functions comes into picture when its protocol specific function.

Actions;

Vuser init(), Action() and Vuser end() are the default actions.

Vuser init()

Actions

Business process 1 – Transaction 1

Business process 2 – Transaction 2

Business process 3 – Transaction 3

Business process 4 – Transaction 4

Vuser end().

These actions can be sequential or random. Priorities can be set.

By default vugen has three different blocks:

Vuser_init()

Action

Vuser_end()

The sequence of execution is vuser_init() à action à vuser_end()

The only block that supports iteration is the action block.

We can divide action block into various used defined blocks in runtime setting à run logic options. By doing this, we can perform multiple tasks with one script.

After we create blocks, we assign steps for each blocks. The sequence of execution of the blocks would be sequential by default i.e. it executes all the user define blocks available in the action block.

In reality user performs one tasks out of n tasks. To achieve this, we can change the sequence of execution of action block into random execution. When we do this, weighing comes in. The sum of weights should be = 100.

In the floating tool bar, click on “Create new action”

Goto runtime settings (F4) à run logic à delete all actions à insert block à insert actions.

To change sequence,

Runtime settings(F4) à run logic à (Right click) properties

Runlogic – Random.

Select individual properties and change the percentage.

Parameterization:

Parameterize is done when:

· Data dependency

· Unique constraints

· Data constraints

Parameterization is a process of replacing hard coded value i.e. input values in the script with a series of values defined in a parameter file.

Ex:

· Password field is a dependent field on the username

· While registering a user, we need to provide user name and email id’s

· Data constraints

Parameterization can be done, by defining values in Vugen or by using an excel sheet.

Following steps to parameterize with vugen:

· Select the value that we want to parameterize. Right click and click on the option à replace with a parameter.

· Create parameter window opens. Give a parameter name, select parameter type as file and click on properties.

· Parameter properties window pops up. Click on create table option.

Parameter properties:

Update values on

· Each Iteration

· Each occurrence

· Once

When unique is selected as “Select next row” when out of values will be populated.

Parameterization can be done with script view and tree view.

When parameterising go to:

Runtime setting à Log à Select extended log à Parameterize substitution

When we parameterize in scripts, to view parameter details in replay log, change log settings from standard to extended log and check the option parameter substitution.

Note:

When ever we search based on search string in our script after recording the script, if we parameterize the search string and run it with iterations there is a possibility of one or more iterations getting failed due to dynamic values generated by server during runtime. To over come this situation we need to correlate the script.

If we add a content check in the script for validating user page and if user name field is parameterized and if more than one iterations is run, there is a possibility of script failing. To avoid this parameterize the content check and the value should change in the same line as user name.

We can pass the parameter values to the script using the excel sheet.

Define column along with values.

Select column along with values.

Go to formulas menu is excel.

Click on define name.

Save the excel sheet.

Go to control panel.

Switch to classic view

Go to administration tools

Click on data source (ODBC)

Click on system DSN tab

Click on add

Select Microsoft excel drivers

Click on finish

ODBC Microsoft excel set up opens

Give a data server name (Source)

Click select work book

Go to the path and select the workbook.

Go to the path and select the excel sheet.

Click ok.

Select the hard coded value. Right click for parameterization. Enter parameter name.

Select properties à click data wizard àspecify SQL statement manually à next.

Click on create to create a connection with DSN.

Click on machine data source.

Select the data source à Click OK.

Write select user name from data in SQL statement.

Vugen à dsl à excel

Shift + F5 is used to compile the script.

Lr_eval_string() is a function used for extracting value of a parameter. When we extract by using this function it returns a character pointer. So we had to declare char pointer (char *a) to fetch the value and we print the value manually in the script by using “lr_output_message(“value of user name is %s”, a)

When a date has to be parameterized, the parameter type should be date/time.

Controller:

Click on run load test to launch controller.

Pre controller launch window is launched when controller is started

Two types of scenarios can be created.

· Manual scenario

· Goal oriented scenario.

Manual scenario	Goal oriented scenario
· Tester can decided ramp up and ramp down duration. · Usually manual scenario is selected. · Can be run in ü Percentage Mode i.e. distribution of load is based on percentage. ü Non percentage mode i.e. distribution of load is based on number of users.	· Tool will automatically decide ramp up and ramp down duration.

Click on browse, select the scripts and click OK.

Design is scenario creation phase.

Scripts are called as “group” in controller.

Note: Run time setting is set for a group i.e. all users within the group will behave identical during script execution.

Controller machine is acting a load generator.

To add vusers, select the row of the group and select the icon create users.

Status down means users are not doing any activity. In the users window click “Add Vusers” button.

Click on “Add group” to add script/group. Select script and add vusers.

Select the group and click on “runtime settings” to set runtime.

Scripts run in controller – set the log to standard log.

Think time: Always select “use select random percentage of recorded think time”

Go to miscellaneous à multi threading à select “run Vuser as a thread” to support more user on the machine.

EX: If MORV consumes 2 MB space, and if we have 50 users, it consumes 100 MB space.

When run as thread, one copy of MORV is shared by 50 users. When run as a process for each user, MORV program is loaded into memory. Consuming more space on RAM by limiting number of users that can be generated on a machine.

Under network à speed simulation à use maximum bandwidth.

Under browser à browser simulation à

Select – simulate a new user on each iteration

§ Clear cache on each iteration

This is done because, client has to hit the server to get the page for each user. If not for each user, he can get the page from the machine itself.

Simulate the browser cache will retain the URL’s.

Modifications done in the scripts in vugen can be reflected in the scrip in the controller by clicking on details à refresh script.

Runtime settings can be done in a similar way.

To see the script in vugen, click on view script.

To add a machine to controlled go to scenario à load generator option.

When controller wants to access load generator it send and connects to RAD i.e. remote agent dispatch.

RAD initiates an agent which is a process running in load generator when controller successfully connects to load generator.

To add click on Add. In the name, give the computer name or IP address of the machine.

My computer à Right click properties à Computer name

To add the machine which we are going to use, ensure that machine is switched on, controller is installed and no one is using the machine.

Select machine and click on connect. When the communication is established between controller and the load generator, the status is set to Ready.

Go to load generator machine

Go to folder where controller is installed.

Go to program files

CD mercury/hp

CD load runner

CD bin.

Run magentservice.exe.

Install load generator in the machine.

Run magentservice.exe.

Ensure controller and load generator are connected.

In the scenario schedule click on timer to set the time for schedule. This is the controller time.

Schedule by scenario	Schedule by group
All scripts follow single schedule i.e. all scripts follow similar ramp up and ramp down.	Different schedule for different group i.e. ramp up and ramp down duration are different for group.

Run mode:

Real life schedule	Run until complete
· In real life schedule we can specify ramp up, duration and ramp down. · It is time based	· Can only specify ramp up. Users run based on the iteration specified in runtime settings. · Iteration based, as settings done in run time settings.

Initiation – Vuser initiation block

Start Vuser duration – action block.

Stop Vuser – Vuser end block.

Global schedule: To change configuration, double click.

Scenario schedule:

Click on initialize à initialize all users simultaneously is to initialize all user at the same time.

Down indicates – no virtual user activity.

Pending indicates – vusers are waiting to run, Vuser init block.

Init indicates vusers are running Vuser init block.

Ready indicates, vusers are waiting to run action block.

Run indicates, vusers are running action block.

Rendezvous instructs vusers to wait until a percentage of users arrive.

Run until complete mode – either pass or fail.

Real life schedule – Gradually exiting, exiting stopped.

In vusers option, separate log file for each Vuser can be seen.

For every user there is a separate log file which can be seen in Vuser option.

Click on Vuser option, select the user and select show Vuser log.

Click run/stop vusers to select the scripts to run or stop.

When clicked on stop in run tab, all selected scripts will stop.

Vusers is running is running Vuser action block.

Elapsed time – text execution time.

Hits/second – no of time client hits the server.

Passed transaction – gives count of all transactions passed.

Failed transaction – gives count of all transactions failed.

Runtime graphs gives info about virtual user and error generated during scripts execution. The most important graph is running vusers graph, error statistics graph and vusers with error graph.

Running vusers graph gives vusers status information.

Error statistics graph gives information about number of errors generated during script execution.

Vusers with error graphs shows the no of errors generated by each virtual user during test run.

Transaction graph:

Giving information about transaction defined in the script. Important graph is transaction response time taken to complete each transaction.

Hits/second is the number of requests from client to server measured every second during test run.

Through put is the amount of data returned by server to client measured in bytes per second.

HTTP response/second gives information about response code generated by server for each request made by client.

For successful resource identification, server generates response code of 200.

Connecting gives information about number of TCP/IP connection established throughout the test run.

Connections/second give number of TCP/IP connections established for each second.

Run time, transaction and web monitor are client side monitors.

Network monitors are used to find out the time spent on the network for a request to reach from client to server and for a response to reach from server to client.

Network delay time is also term as round trip time or latency.

View à view graphs à custom number to view 16 graphs in the graph viewing area.

NOTE:

When we stop vusers, they stop doin there activity based on stop configuration set in tools à options à run time settings.

When stopping vusers:

· Wait for current iteration to end before stopping.

· Wait for current action to end before stopping

· Stop immediately

Test duration time or elapsed time = start Vuser time + duration time + stop vusers time.

To search within the log file, click on find text.

To insert rendezvous:

Select the script in design tab à vugen scripts à insert rendezvous à give name.

Function name is rendezvous – lr_rendezvous(“wait”)

After changes save the script.

Scenario à rendezvous à policy à select the second policy.

To launch analysis directly from controller go to results menu and click on “Auto load analysis”.

To launch vugen and analysis from command prompt:

C:\\\program files\mercury of hp\load runner\bin\vugen.exe.

C:\\\program files\mercury of hp\load runner\bin\wlran.exe for controller.

C:\\\program files\mercury of hp\load runner\bin\analysisui.exe for analysis.

Analysis:

Steps in analysis:

1. Set service level agreements (SLA) by going to tools à configure SLA rules options.

2. Analysis automatically compares the actual results with expected results defined in SLA roots

3. Now go to transaction summary table in the summary report and look at the value for each transaction in 90% column.

4. After identifying problematic transaction in transaction summary table filter out transaction response time graph to show only problematic transaction.

5. Now merge number of users graph with transaction response time graph to check the effect of load on response time.

6. Now analyze hits per second graph.

7. Analyze through put graph.

8. Make user notes for the analysis graph.

9. Now generate performance report in either html or word format

.lra is the extension of the files

Controller à results à auto load analysis à open analysis from controller.

Converts .lrr to .lrl.

To manually open analysis – results à analyse results.

SLA tab can also be seen in the controller.

To create SLA (goal) click on

New à next à select average transaction response time à next à press control and select more than one transaction.

Click Add à next àrunning vusers.

Load value can be defined on

Load criteria à next à apply to all transactions à next à finish when close – tool compares actual with SLA.

To add a graph, click

Add graph à transaction à average transaction graph.

To filter graph:

Right click on graph à select set filter/group by à select the transaction à click OK.

Above filter condition is transaction name.

Graph can be merged only when x-axis values are same.

To merge graphs – right click on graph à merge graph.

When two graphs are merged, the y axis of the first graph becomes the x-axis for the merged graph and y-axis of the second graph will be the y-axis.

The common x-axis goes off.

User notes can be written as Direct correlation between user and response time in user notes.

Granularity is used to define how frequently we need to get data for each monitored graph.

If hits/second is flat, then there is a web server connectivity issue.

(Example, for hit/second graph – notes can be – no web connectivity issues).

Through put graph: Through put is the data coming from server to client. If the graph is flat, its network bandwidth issue. Graph should be variable.

Notes can be – no network bandwidth issue.

To check server comparison – go to à problematic transaction à right click à auto correlate.

For this select the markers between the peak.

To generate report –

Report à HTML report – save.

HTML report cannot be modified and non formattable.

Report à word report.

To create a template:

Tools à template àsave as template

Tools à template àapply edit template – to open the analysis