Saturday, February 4, 2012

Loadrunner interview question



Q.1: What is Load Testing?
Load testing is to test that if the application works fine with the loads that result from large number of simultaneous users, transactions and to determine weather it can handle peak usage periods.
<<<<<< =================== >>>>>>
Q.2: What is Performance testing?
Timing for both read and update transactions should be gathered to determine whether system functions are being performed in an acceptable timeframe. This should be done standalone and then in a multi user environment to determine the effect of multiple transactions on the timing of a single transaction.
<<<<<< =================== >>>>>>
Q.3: Briefly explain as to what is LoadRunner?
LoadRunner works by creating virtual users who take the place of real users operating client software, such as sending requests using the HTTP protocol to IIS or Apache web servers. Requests from many virtual user clients are generated by Load Generators in order to create a load on various servers under test
These load generator agents are started and stopped by Mercury's Controller program. The Controller controls load test runs based on Scenarios invoking compiled Scripts and associated Run-time Settings.
Scripts are crafted using Mercury's "Virtual user script Generator" (named "V U Gen"), It generates C-language script code to be executed by virtual users by capturing network traffic between Internet application clients and servers.
With Java clients, VuGen captures calls by hooking within the client JVM. During runs, the status of each machine is monitored by the Controller.
At the end of each run, the Controller combines its monitoring logs with logs obtained from load generators, and makes them available to the "Analysis" program, which can then create run result reports and graphs for Microsoft Word, Crystal Reports, or an HTML webpage browser.
Each HTML report page generated by Analysis includes a link to results in a text file, which Microsoft Excel can open to perform additional analysis.
Errors during each run are stored in a database file, which can be read by Microsoft Access.
<<<<<< =================== >>>>>>
Q.4: What is a Virtual User?
Unlike a WinRunner workstation, which emulates a single user's use of a client, LoadRunner can emulate thousands of Virtual Users.
Load generators are controlled by VuGen scripts, which issue non-GUI API calls using the same protocols as the client under test. But WinRunner GUI Vusers emulate keystrokes, mouse clicks, and other User Interface actions on the client being tested.
Only one GUI user can run from a machine unless LoadRunner Terminal Services Manager manages remote machines with Terminal Server Agent enabled and logged into a Terminal Services Client session.
During run-time, threadedvusers share a common memory pool. So threading supports more Vusers per load generator.
The Status of Vusers on all load generators start from "Running", then go to "Ready" after going through the init section of the script. Vusers are "Finished" in passed or failed end status. Vusers are automatically "Stopped" when the Load Generator is overloaded.
To use Web Services Monitors for SOAP and XML, a separate license is needed, and vUsers require the Web Services add-in installed with Feature Pack (FP1).
No additional license is needed for standard web (HTTP) server monitors Apache, IIS, and Netscape.
<<<<<< =================== >>>>>>
Q.5: How do we use Windows Remote Desktop Connection?
To keep Windows Remote Desktop Connection sessions from timing out during a test, the Terminal Services on each machine should be configured as follows:
Click Start, point to Programs (or Control Panel), Administrative Tools and choose Terminal Services Configuration.
Open the Connections folder in tree by clicking it once.
Right-click RDP-Tcp and select Properties.
Click the Sessions tab.
Make sure "Override user settings" is checked.
Set Idle session limit to the maximum of 2 days instead of the default 2 hours.
Click Apply.
Click OK to confirm message "Configuration changes have been made to the system registry; however, the user session now active on the RDP-Tcp connection will not be changed."
<<<<<< =================== >>>>>>
Q.6: Briefly explain the Load testing process using LoadRunner?
Step 1: Planning the test: Here, we develop a clearly defined test plan to ensure the test scenarios we develop will accomplish load-testing objectives.
Step 2: Creating Vusers: Here, we create Vuser scripts that contain tasks performed by each Vuser, tasks performed by Vusers as a whole, and tasks measured as transactions.
Step 3: Creating the scenario: A scenario describes the events that occur during a testing session. It includes a list of machines, scripts, and Vusers that run during the scenario. We create scenarios using LoadRunner Controller. We can create manual scenarios as well as goal-oriented scenarios. In manual scenarios, we define the number of Vusers, the load generator machines, and percentage of Vusers to be assigned to each script. For web tests, we may create a goal-oriented scenario where we define the goal that our test has to achieve. LoadRunner automatically builds a scenario for us.
Step 4: Running the scenario: We emulate load on the server by instructing multiple Vusers to perform tasks simultaneously. Before the testing, we set the scenario configuration and scheduling. We can run the entire scenario, Vuser groups, or individual Vusers.
Step 5: Monitoring the scenario: We monitor scenario execution using the LoadRunner online runtime, transaction, system resource, Web resource, Web server resource, Web application server resource, database server resource, network delay, streaming media resource, firewall server resource, ERP server resource, and Java performance monitors.
Step 6: Analyzing test results: During scenario execution, LoadRunner records the performance of the application under different loads. We use LoadRunner’s graphs and reports to analyze the application’s performance.
<<<<<< =================== >>>>>>
Q.7: When do you do load and performance Testing?
We perform load testing once we are done with interface (GUI) testing. Modern system architectures are large and complex. Whereas single user testing primarily on functionality and user interface of a system component, application testing focuses on performance and reliability of an entire system.
For example, a typical application-testing scenario might depict 1000 users logging in simultaneously to a system. This gives rise to issues such as what is the response time of the system, does it crash, will it go with different software applications and platforms, can it hold so many hundreds and thousands of users, etc. This is when we set do load and performance testing.
<<<<<< =================== >>>>>>
Q.8: What are the components of LoadRunner?
The components of LoadRunner are The Virtual User Generator, Controller, and the Agent process, LoadRunner Analysis and Monitoring, LoadRunner Books Online.
<<<<<< =================== >>>>>>
Q.9: What Component of LoadRunner would you use to record a Script?
The Virtual User Generator (VuGen) component is used to record a script. It enables you to develop Vuser scripts for a variety of application types and communication protocols.
<<<<<< =================== >>>>>>
Q.10: What is the role of Remote Agent Dispatcher in LoadRunner?
The role of Remote Agent Dispatcher is to enable the Controller to start applications on the load generator.
Q.11: What is a function to capture dynamic values in the web vuser script?

Web_reg_save_param function saves dynamic data information to a parameter.

<<<<<< =================== >>>>>>
Q.12: What Component of LoadRunner would you use to play Back the script in multi user mode?
The Controller component is used to playback the script in multi-user mode. This is done during a scenario run where a vuser script is executed by a number of vusers in a group.
<<<<<< =================== >>>>>>
Q.13: What is a rendezvous point?
You insert rendezvous points into Vuser scripts to emulate heavy user load on the server. Rendezvous points instruct Vusers to wait during test execution for multiple Vusers to arrive at a certain point, in order that they may simultaneously perform a task. For example, to emulate peak load on the bank server, you can insert a rendezvous point instructing 100 Vusers to deposit cash into their accounts at the same time.
<<<<<< =================== >>>>>>
Q.14: What is a scenario?
A scenario defines the events that occur during each testing session. For example, a scenario defines and controls the number of users to emulate, the actions to be performed, and the machines on which the virtual users run their emulations.
<<<<<< =================== >>>>>>
Q.15: Explain the recording mode for web Vuser script?
We use VuGen to develop a Vuser script by recording a user performing typical business processes on a client application. VuGen creates the script by recording the activity between the client and the server. For example, in web based applications, VuGen monitors the client end of the database and traces all the requests sent to, and received from, the database server. We use VuGen to: Monitor the communication between the application and the server; Generate the required function calls; and Insert the generated function calls into a Vuser script.
<<<<<< =================== >>>>>>
Q.16: Why do you create parameters?
Parameters are like script variables. They are used to vary input to the server and to emulate real users. Different sets of data are sent to the server each time the script is run. Better simulate the usage model for more accurate testing from the Controller; one script can emulate many different users on the system.
<<<<<< =================== >>>>>>
Q.17: What is correlation? Explain the difference between automatic correlation and manual correlation?
Correlation is used to obtain data which are unique for each run of the script and which are generated by nested queries. Correlation provides the value to avoid errors arising out of duplicate values and also optimizing the code (to avoid nested queries). Automatic correlation is where we set some rules for correlation. It can be application server specific. Here values are replaced by data which are created by these rules. In manual correlation, the value we want to correlate is scanned and create correlation is used to correlate.
<<<<<< =================== >>>>>>
Q.18: How do you find out where correlation is required?
Two ways: First we can scan for correlations, and see the list of values which can be correlated. From this we can pick a value to be correlated. Secondly, we can record two scripts and compare them. We can look up the difference file to see for the values which needed to be correlated.
<<<<<< =================== >>>>>>
Q.19: Where do you set automatic correlation options?
Automatic correlation from web point of view can be set in recording options and correlation tab. Here we can enable correlation for the entire script and choose either issue online messages or offline actions, where we can define rules for that correlation. Automatic correlation for database can be done using show output window and scan for correlation and picking the correlate query tab and choose which query value we want to correlate. If we know the specific value to be correlated, we just do create correlation for the value and specify how the value to be created.
<<<<<< =================== >>>>>>
Q.20: What is a function to capture dynamic values in the web Vuser script?
Web_reg_save_param function saves dynamic data information to a parameter.
Q.21: VuGen Recording and Scripting?
LoadRunner script code obtained from recording in the ANSI C language syntax, represented by icons in icon view until you click Script View.
<<<<<< =================== >>>>>>
Q.22: What are Scenarios?
Scenarios encapsulate the Vuser Groups and scripts to be executed on load generators at run-time.
Manual scenarios can distribute the total number of Vusers among scripts based on the analyst-specified percentage (evenly among load generators).
Goal Oriented scenarios are automatically created based on a specified transaction response time or number of hits/transactions-per-second (TPS). Test analysts specify the % of Target among scripts.
<<<<<< =================== >>>>>>
Q.23: When do you disable log in Virtual User Generator, When do you choose standard and extended logs?
Once we debug our script and verify that it is functional, we can enable logging for errors only. When we add a script to a scenario, logging is automatically disabled.
Standard Log Option: When you select Standard log, it creates a standard log of functions and messages sent during script execution to use for debugging. Disable this option for large load testing scenarios. When you copy a script to a scenario, logging is automatically disabled
Extended Log Option: Select extended log to create an extended log, including warnings and other messages. Disable this option for large load testing scenarios. When you copy a script to a scenario, logging is automatically disabled. We can specify which additional information should be added to the extended log using the Extended log options.
<<<<<< =================== >>>>>>
Q.24: How do you debug a LoadRunner script?
VuGen contains two options to help debug Vuser scripts-the Run Step by Step command and breakpoints. The Debug settings in the Options dialog box allow us to determine the extent of the trace to be performed during scenario execution.
The debug information is written to the Output window. We can manually set the message class within your script using the lr_set_debug_message function.
This is useful if we want to receive debug information about a small section of the script only.
<<<<<< =================== >>>>>>
Q.25: How do you write user defined functions in LoadRunner?
Before we create the User Defined functions we need to create the external library (DLL) with the function.
We add this library to VuGen bin directory. Once the library is added then we assign user defined function as a parameter.
The function should have the format: __declspec (dllexport) char* (char*, char*)
<<<<<< =================== >>>>>>
Q.26: What are the changes you can make in run-time settings?
The Run Time Settings that we make are:
Pacing - It has iteration count.
Log - Under this we have Disable Logging Standard Log and
Extended Think Time - In think time we have two options like Ignore think time and Replay think time.
General - Under general tab we can set the vusers as process or as multithreading and whether each step as a transaction.
<<<<<< =================== >>>>>>
Q.27: Where do you set Iteration for Vuser testing?
We set Iterations in the Run Time Settings of the VuGen. The navigation for this is Run time settings, Pacing tab, set number of iterations.
<<<<<< =================== >>>>>>
Q.28: How do you perform functional testing under load?
Functionality under load can be tested by running several Vusers concurrently.
By increasing the amount of Vusers, we can determine how much load the server can sustain.
<<<<<< =================== >>>>>>
Q.29: How do we use network drive mappings?
If several load generators need to access the same physical files, rather than having to remember to copy the files each time they change, each load generator can reference a common folder using a mapped drive. But since drive mappings are associated with a specific user:
Logon the load generator as the user the load generator will use
Open Windows Explorer and under Tools select Map a Network Drive and create a drive. It saves time and hassle to have consistent drive letters across load generators, so some organizations reserve certain drive letters for specific locations.
Open the LoadRunner service within Services (accessed from Control Panel, Administrative Tasks), Click the "Login" tab.
Specify the username and password the load generator service will use. (A dot appears in front of the username if the userid is for the local domain).
Stop and start the service again.
<<<<<< =================== >>>>>>
Q.30: What is Ramp up? How do you set this?
This option is used to gradually increase the amount of Vusers/load on the server.
An initial value is set and a value to wait between intervals can be specified.
To set Ramp Up, go to ‘Scenario Scheduling Options’
Q.31: What is the advantage of running the Vuser as thread?
VuGen provides the facility to use multithreading.
This enables more Vusers to be run per generator. If the Vuser is run as a process, the same driver program is loaded into memory for each Vuser, thus taking up a large amount of memory.
This limits the number of Vusers that can be run on a single generator.
If the Vuser is run as a thread, only one instance of the driver program is loaded into memory for the given number of Vusers (say 100).
Each thread shares the memory of the parent driver program, thus enabling more Vusers to be run per generator.
<<<<<< =================== >>>>>>
Q.32: How can we stop the execution of our script on error?
The lr_abort function aborts the execution of a Vuser script.
It instructs the Vuser to stop executing the Actions section, execute the vuser_end section and end the execution.
This function is useful when you need to manually abort a script execution as a result of a specific error condition.
When you end a script using this function, the Vuser is assigned the status "Stopped".
For this to take effect, we have to first uncheck the Continue on error option in Run-Time Settings.
<<<<<< =================== >>>>>>
Q.33: What is the relation between Response Time and Throughput?
The Throughput graph shows the amount of data in bytes that the Vusers received from the server in a second.
When we compare this with the transaction response time, we will notice that as throughput decreased, the response time also decreased.
Similarly, the peak throughput and highest response time would occur approximately at the same time.
<<<<<< =================== >>>>>>
Q.34: Explain the Configuration of your systems?
The configuration of our systems refers to that of the client machines on which we run the Vusers. The configuration of any client machine includes its hardware settings, memory, operating system, software applications, development tools, etc. This system component configuration should match with the overall system configuration that would include the network infrastructure, the web server, the database server, and any other components that go with this larger system so as to achieve the load testing objectives.
<<<<<< =================== >>>>>>
Q.35: How do you identify the performance bottlenecks?
Performance Bottlenecks can be detected by using monitors. These monitors might be application server monitors, web server monitors, database server monitors and network monitors.
They help in finding out the troubled area in our scenario which causes increased response time. The measurements made are usually performance response time, throughput, hits/sec, network delay graphs, etc.
<<<<<< =================== >>>>>>
Q.36: If web server, database and Network are all fine where could be the problem?
The problem could be in the system itself or in the application server or in the code written for the application.
<<<<<< =================== >>>>>>
Q.37: How did you find web server related issues?
Using Web resource monitors we can find the performance of web servers. Using these monitors we can analyze throughput on the web server, number of hits per second that occurred during scenario, the number of http responses per second, the number of downloaded pages per second.
<<<<<< =================== >>>>>>
Q.38: How do you find out the database-related issues?
By running Database monitor and help of Data Resource Graph we can find database-related issues.
E.g. You can specify the resource you want to measure on before running the controller and than you can see database related issues.
<<<<<< =================== >>>>>>
Q.39: What is the difference between Overlay graph and Correlate graph?
Overlay Graph: It overlay the content of two graphs that shares a common x-axis. Left Y-axis on the merged graph show’s the current graph’s value & Right Y-axis show the value of Y-axis of the graph that was merged.
Correlate Graph: Plot the Y-axis of two graphs against each other. The active graph’s Y-axis becomes X-axis of merged graph. Y-axis of the graph that was merged becomes merged graph’s Y-axis.
<<<<<< =================== >>>>>>
Q.40: How did you plan the Load? What are the Criteria?
Load test is planned to decide the number of users, what kind of machines we are going to use and from where they are run.
It is based on 2 important documents, Task Distribution Diagram and Transaction profile.
Task Distribution Diagram gives us the information on number of users for a particular transaction and the time of the load. The peak usage and off-usage are decided from this Diagram.
Transaction profile gives us the information about the transaction name and their priority levels with regard to the scenario we are deciding.
Q.41: What does vuser_init action contain?
Vuser_init action contains procedures to login to a server.
<<<<<< =================== >>>>>>
Q.42: What does vuser_end action contain?
Vuser_end section contains log off procedures.
<<<<<< =================== >>>>>>
Q.43: What is think time? How do you change the threshold?
Think time is the time that a real user waits between actions. Example: When a user receives data from a server, the user may wait several seconds to review the data before responding. This delay is known as the think time. Changing the Threshold: Threshold level is the level below which the recorded think time will be ignored. The default value is five (5) seconds. We can change the think time threshold in the Recording options of the Vugen.
<<<<<< =================== >>>>>>
Q.44: What is the difference between standard log and extended log?
The standard log sends a subset of functions and messages sent during script execution to a log.
The subset depends on the Vuser type.

Extended log sends a detailed script execution messages to the output log.

This is mainly used during debugging when we want information about: 1) Parameter substitution. 2) Data returned by the server. 3) Advanced trace.

<<<<<< =================== >>>>>>
Q.45: What is lr_debug_message ?
The lr_debug_message function sends a debug message to the output log when the specified message class is set.
<<<<<< =================== >>>>>>
Q.46: What is lr_output_message ?
The lr_output_message function sends notifications to the Controller Output window and the Vuser log file.
<<<<<< =================== >>>>>>
Q.47: What is lr_error_message ?
The lr_error_message function sends an error message to the LoadRunner Output window.
<<<<<< =================== >>>>>>
Q.48: What is lrd_stmt?
The lrd_stmt function associates a character string (usually a SQL statement) with a cursor. This function sets a SQL statement to be processed.
<<<<<< =================== >>>>>>
Q.49: What is lrd_fetch?
The lrd_fetch function fetches the next row from the result set.
<<<<<< =================== >>>>>>
Q.50: What is Throughput?
If the throughput scales upward as time progresses and the number of Vusers increase, 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.
Q.51: How many types of Goals are there in Goal-Oriented Scenario?
Load Runner provides following types of goals in a goal oriented scenario:
1) The number of concurrent Vusers
2) The number of hits per second
3) The number of transactions per second
4) The number of pages per minute
<<<<<< =================== >>>>>>
Q.52: What is correlation? Explain the difference between automatic correlation and manual correlation?
Correlation is used to obtain data which are unique for each run of the script and which are generated by nested queries. Correlation provides the value to avoid errors arising out of duplicate values and also optimizing the code (to avoid nested queries).
Automatic correlation is where we set some rules for correlation. It can be application server specific. Here values are replaced by data which are created by these rules. In manual correlation, the value we want to correlate is scanned and create correlation is used to correlate.
<<<<<< =================== >>>>>>
Q.53: Where do you set automatic correlation options?
Automatic correlation from web point of view, can be set in recording options and correlation tab. Here we can enable correlation for the entire script and choose either issue online messages or offline actions, where we can define rules for that correlation.
Automatic correlation for database, can be done using show output window and scan for correlation and picking the correlate query tab and choose which query value we want to correlate. If we know the specific value to be correlated, we just do create correlation for the value and specify how the value to be created.
<<<<<< =================== >>>>>>
Q.54: What is the utility of Analysis module of HP LoadRunner?
LoadRunner enables you to test your system under controlled and peak load conditions.
Whereas Analysis module of LoadRunner provides in–depth reports and graphs hilighting the information that you need to evaluate the performance of your application.
<<<<<< =================== >>>>>>
Q.55: What is Analysis Graphs?
It is a tool to view a summary of the results after the load test scenario execution.
The Analysis graphs help you determine system performance and provide information about transactions and Vusers. You can compare multiple graphs by combining results from several load test scenarios or merging several graphs into one.
<<<<<< =================== >>>>>>
Q.56: What is the Graph Data and Raw Data views?
These are the tool to view a summary of the results after the load test scenario execution.
The Graph Data and Raw Data views display the actual data used to generate the graph in a spreadsheet format. You can copy this data into external spreadsheet applications for further processing.
<<<<<< =================== >>>>>>
Q.57: How do we create Analysis Sessions?
When you run a load test scenario, data is stored in a result file with an .lrr extension. Analysis is the utility that processes the gathered result information and generates graphs and reports.
When you work with the Analysis utility, you work within a session.
An Analysis session contains at least one set of scenario results (.lrr file).
Analysis stores the display information and layout settings for the active graphs in a file with an .lra extension.
<<<<<< =================== >>>>>>
Q.58: How do we launch the Analysis utility?
You can open Analysis as an independent application or directly from the Controller.
To open Analysis as an independent application, choose one of the following:
# Start > Programs > LoadRunner > Applications > Analysis
# Start > Programs > LoadRunner > LoadRunner, select the Load Testing tab,and then click Analyze Load Tests.
To open Analysis directly from the Controller:
Select Results > Analyze Results.
This option is only available after running a load test scenario. Analysis takes the latest result file from the current scenario, and opens a new session using these results.
You can also instruct the Controller to automatically open Analysis after it completes scenario execution by selecting Results > Auto Load Analysis.
<<<<<< =================== >>>>>>
Q.59: How can we view the summary of the data when we happen to process heavy data say more than 100 Mb?
In large load test scenarios, with results exceeding 100 MB, it can take a long time for Analysis to process the data. While LoadRunner is processing the complete data, you can view a summary of the data.
To view the summary data, choose Tools > Options, and select the Result Collection tab. To process the complete data graphs while you view the summary data, select Display summary data while generating complete data, or select Generate summary data only if you do not want LoadRunner to process the complete Analysis data.
<<<<<< =================== >>>>>>
Q.60: What type of Analysis graphs are available?
Try to remember names & utility of few of the graphs & present in case of need in the interview.
Following types of graphs are available in Analysis module of LoadRunner.
1) Vuser Graphs: Provide information about Vuser states and other Vuser statistics.
2) Error Graphs: Provide information about the errors that occurred during the load test scenario.
3) Transaction Graphs: Provide information about transaction performance and response time.
4) Web Resource Graphs: Provide information about the throughput, hits per second, HTTP responses per second, number of retries per second, and downloaded pages per second for Web Vusers.
5) Web Page Diagnostics Graphs: Provide information about the size and download time of each Web page component.
6) User-Defined Data Point Graphs: Provide information about the custom data points that were gathered by the online monitor.
7) System Resource Graphs: Provide statistics relating to the system resources that were monitored during the load test scenario using the online monitor. This category also includes graphs for SNMP monitoring.
8) Network Monitor Graphs: Provide information about the network delays.
9) Firewall Server Monitor Graphs: Provide information about firewall server resource usage.
10) Web Server Resource Graphs: Provide information about the resource usage for the Apache, iPlanet/Netscape, iPlanet(SNMP), and MS IIS Web servers.
11) Web Application Server Resource Graphs: Provide information about the resource usage for various Web application servers.
12) Database Server Resource Graphs: Provide information about database resources.
13) Streaming Media Graphs: Provide information about resource usage of streaming media.
14) ERP/CRM Server Resource Graphs: Provide information about ERP/CRM server resource usage.
15) Java Performance Graphs: Provide information about resource usage of Java-based applications.
16) Application Component Graphs: Provide information about resource usage of the Microsoft COM+ server and the Microsoft NET CLR server.
17) Application Deployment Solutions Graphs: Provide information about resource usage of the Citrix MetaFrame and 1.8 servers.
18) Middleware Performance Graphs: Provide information about resource usage of the Tuxedo and IBM WebSphere MQ servers.
19) Infrastructure Resources Graphs: Provide information about resource usage of FTP, POP3, SMTP, IMAP, and DNS Vusers on the network client.
20) Siebel Diagnostics Graphs: Provide detailed breakdown diagnostics for transactions generated on Siebel Web, Siebel App, and Siebel Database servers.
21) Siebel DB Diagnostics Graphs: Provide detailed breakdown diagnostics for SQLs generated by transactions on the Siebel system.
22) Oracle 11i Diagnostics Graphs: Provide detailed breakdown diagnostics for SQLs generated by transactions on the Oracle NCA system.
23) SAP Diagnostics Graphs: Provide detailed breakdown diagnostics for SAP data generated by transactions on the SAP Server.
24) J2EE & .NET Diagnostics Graphs: Provide information to trace, time, and troubleshoot individual transactions through J2EE & .NET Web, application, and database servers.
Q.61: Which information is not available while viewing the summary data?
The following graphs are not available when viewing summary data only:
1) Data Point (Sum)
2) Error
3) Network Monitor
4) Rendezvous
5) Siebel DB Side Transactions
6) Siebel DB Side Transactions by SQL Stage
7) SQL Average Execution Time
8) Web Page Diagnostics
<<<<<< =================== >>>>>>
Q.62: How do we open the Graphs and Reports?
You access Analysis graphs and reports from the Session Explorer Window (Windows > Session Explorer).
You add graphs to the Session Explorer using the Open a New Graph dialog box.
<<<<<< =================== >>>>>>
Q.63: What is the Session Explorer Window & what are its constituents?
The Session Explorer (Windows > Session Explorer) displays a tree view of the items (graphs and reports) that are open in the current session.When you click an item in the Session Explorer, it is activated in the main Analysis window.
The Session Explorer is divided into the following categories.
1) Summary Report: Click this node to access the Summary report (wherever available).
2) Service Level Agreement: Expand this node to access the SLA (Service Level Agreement) reports.
3) Analyzed Transactions: Expand this node to access the Transaction Analysis reports.
4) Graphs: Expand this node to access the Analysis graphs. To open another graph or create a duplicate of an existing one, choose Graph > Add New Graph.
<<<<<< =================== >>>>>>
Q.64: How do we generate or display Graphs?
Click Open Graph.
Analysis generates the selected graph and adds it to the Session Explorer. The graph is displayed in the main Analysis window.
To display an existing graph in the right pane of the Analysis window, select the graph in the Session Explorer.
<<<<<< =================== >>>>>>
Q.65: How can we do the repositioning and docking of Analysis Windows?
You can reposition any window by dragging it to the desired position on the screen. You can dock a window by dragging the window and using the arrows of the guide diamond to dock the window in the desired position.
Docking of a window: Assume, for example, that you want to dock the Legend window so that it is displayed below the Session Explorer window.
1) Ensure that Windows > Layout locked is not selected.
2) Select the Legend window and drag it to the Session Explorer window.
A guide diamond opens in the middle of the Session Explorer. Each arrow on the guide diamond represents the position of the Legend window on the screen, relative to the Session Explorer.
3) Place the Legend window on the bottom arrow of the guide diamond. The Legend window appears below the Session Explorer.
You can set a window to floating mode by double-clicking the window’s title bar. The window undocks and floats above all the other windows. To dock the window back into position, double-click the title bar again.
<<<<<< =================== >>>>>>
Q.66: What is Aggregation of Data?
When you choose to generate the complete Analysis data, Analysis aggregates the data.
Aggregation process reduces the size of the database and decreases processing time in large load test scenarios.
<<<<<< =================== >>>>>>
Q.67: What is the use of Result Collection Tab in the Options Dialog Box?
You use the Result Collection tab of the Options dialog box to configure data options.
In large load test scenarios, with results exceeding 100 MB, it will take several minutes for Analysis to process the data.
The Result Collection tab of the Options dialog box enables you to indicate to LoadRunner to display a summary of the data, while you wait for the complete data to be processed.
<<<<<< =================== >>>>>>
Load & Stress Testing of websites
<<<<<< =================== >>>>>>
Q.68: Why Scalability and Load Testing is Important?
Some very high profile websites have suffered from serious outages and/or performance issues due to the number of people hitting their website. E-commerce sites that spent heavily on advertising but not nearly enough on ensuring the quality or reliability of their service have ended up with poor web-site performance, system downtime and/or serious errors, with the predictable result that customers are being lost.
In the case of ToysRUS, its web site couldn't handle the approximately 1000 percent increase in traffic that their advertising campaign generated. Similarly, Encyclopaedia Britannica was unable to keep up with the amount of users during the immediate weeks following their promotion of free access to its online database. The truth is, these problems could probably have been prevented, had adequate load testing taken place.
When creating an e-Commerce portal, companies will want to know whether their infrastructure can handle the predicted levels of traffic, to measure performance and verify stability.
These types of services include Scalability / Load / Stress testing, as well as Live Performance Monitoring.
Load testing tools can be used to test the system behavior and performance under stressful conditions by emulating thousands of virtual users. These virtual users stress the application even harder than real users would, while monitoring the behavior and response times of the different components. This enables companies to minimize test cycles and optimize performance, hence accelerating deployment, while providing a level of confidence in the system.
Once launched, the site can be regularly checked using Live Performance Monitoring tools to monitor site performance in real time, in order to detect and report any performance problems - before users can experience them.
<<<<<< =================== >>>>>>
Q.69: How do we prepare for a Load Test?
The first step in designing a Web site load test is to measure as accurately as possible the current load levels.
Measuring Current Load Levels:
The best way to capture the nature of Web site load is to identify and track, [e.g. using a log analyzer] a set of key user session variables that are applicable and relevant to your Web site traffic.
Some of the variables that could be tracked include:
1) The length of the session (measured in pages)
2) The duration of the session (measured in minutes and seconds)
3) The type of pages that were visited during the session (e.g., home page, product information page, credit card information page etc.)
4) The typical/most popular ‘flow’ or path through the website
5) The % of ‘browse’ vs. ‘purchase’ sessions
6) The % type of users (new user vs. returning registered user)
Measure how many people visit the site per week/month or day.

Then break down these current traffic patterns into one-hour time slices, and identify the peak-hours (i.e. if you get lots of traffic during lunchtime etc.), and the numbers of users during those peak hours.

This information can then be used to estimate the number of concurrent users on your site.

<<<<<< =================== >>>>>>
Q.70: What is the meaning of Concurrent Users?
Although your site may be handling x number of users per day, only a small percentage of these users would be hitting your site at the same time.

For example, if you have 3000 unique users hitting your site on one day, all 3000 are not going to be using the site between 11.01 and 11.05 am.

So, once you have identified your peak hour, divide this hour into 5 or 10 minute slices [you should use your own judgement here, based on the length of the average user session] to get the number of concurrent users for that time slice.
Q.71: Estimating Target Load Levels
Once you have identified the current load levels, the next step is to understand as accurately and as objectively as possible the nature of the load that must be generated during the testing.
Using the current usage figures, estimate how many people will visit the site per week/month or day. Then divide that number to attain realistic peak-hour scenarios.
It is important to understand the volume patterns, and to determine what load levels your web site might be subjected to (and must therefore be tested for).
There are four key variables that must be understood in order to estimate target load levels:
1) How the overall amount of traffic to your Web site is expected to grow
2) The peak load level which might occur within the overall traffic
3) How quickly the number of users might ramp up to that peak load level
4) How long that peak load level is expected to last
Once you have an estimate of overall traffic growth, you’ll need to estimate the peak level you might expect within that overall volume.
<<<<<< =================== >>>>>>
Q.72: How do we estimate the Test Duration?
The duration of the peak is also very important. A Web site that may deal very well with a peak level for five or ten minutes may crumble if that same load level is sustained longer than that.

You should use the length of the average user session as a base for determining the load test duration.

<<<<<< =================== >>>>>>
Q.73: What is Ramp-up Rate?
As mentioned earlier, Although your site may be handling x number of users per day, only a small percentage of these users would be hitting your site at the same time.
Therefore, when preparing your load test scenario, you should take into account the fact that users will hit the website at different times, and that during your peak hour the number of concurrent users will likely gradually build up to reach the peak number of users, before tailing off as the peak hour comes to a close.
The rate at which the number of users build up, the "Ramp-up Rate" should be factored into the load test scenarios (i.e. you should not just jump to the maximum value, but increase in a series of steps).
<<<<<< =================== >>>>>>
Q.74: How to create the scenarios that are to be used to load test the web site?
The information gathered during the analysis of the current traffic is used to create the scenarios that are to be used to load test the web site.
The identified scenarios aim to accurately emulate the behavior of real users navigating through the Web site.
For example, a seven-page session that results in a purchase is going to create more load on the Web site than a seven-page session that involves only browsing. A browsing session might only involve the serving of static pages, while a purchase session will involve a number of elements, including the inventory database, the customer database, a credit card transaction with verification going through a third-party system, and a notification email. A single purchase session might put as much load on some of the system’s resources as twenty browsing sessions.
Similar reasoning may apply to purchases from new vs. returning users.

A new user purchase might involve a significant amount of account setup and verification something existing users may not require.

The database load created by a single new user purchase may equal that of five purchases by existing users, so you should differentiate the two types of purchases.

<<<<<< =================== >>>>>>
Q.75: How to prepare a script to run each scenario with the number of types of users concurrently playing back to give you a load scenario?
Using the load test tool, write the scripts to run each scenario with the number of types of users concurrently playing back to give you a load scenario.
The key elements of a load test design are:
1) Test objective
2) Pass/fail criteria
3) Script description
4) Scenario description

Load Test Objective:
The objective of this load test is to determine if the Web site, as currently configured, will be able to handle the X number of sessions/hr peak load level anticipated. If the system fails to scale as anticipated, the results will be analyzed to identify the bottlenecks.
Pass/Fail Criteria: The load test will be considered a success if the Web site will handle the target load of X number of sessions/hr while maintaining the pre-defined average page response times (if applicable). The page response time will be measured and will represent the elapsed time between a page request and the time the last byte is received.
Since in most cases the user sessions follow just a few navigation patterns, you will not need hundreds of individual scripts to achieve realism—if you choose carefully, a dozen scripts will take care of most Web sites.
<<<<<< =================== >>>>>>
Q.76: How To Create a Load Testing Scenario?
Scripts should be combined to describe a load-testing scenario. A basic scenario includes the scripts that will be executed, the percentages in which those scripts will be executed, and a description of how the load will be ramped up.
By emulating multiple business processes, the load testing can generate a load equivalent to X numbers of virtual users on a Web application. During these load tests, real-time performance monitors are used to measure the response times for each transaction and check that the correct content is being delivered to users. In this way, they can determine how well the site is handling the load and identify any bottlenecks.
The execution of the scripts opens X number of HTTP sessions (each simulating a user) with the target Web site and replays the scripts over and over again. Every few minutes it adds X more simulated users and continue to do so until the web site fails to meet a specific performance goal.
<<<<<< =================== >>>>>>
Q.77: Why System Performance Monitoring Is Important?
It is vital during the execution phase to monitor all aspects of the website. This includes measuring and monitoring the CPU usage and performance aspects of the various components of the website, i.e. not just the web-server, but the database and other parts as well (such as firewalls, load balancing tools etc.)
You can quote following examples:
1) One e-tailor, whose site fell over (apparently due to a high load), when analyzing the performance bottlenecks on their site discovered that the web-server had in fact only been operating at 50% of capacity. Further investigation revealed that the credit card authorization engine was the cause of failure - it was not responding quick enough for the website, which then fell over when it was waiting for too many responses from the authorization engine. They resolved this issue by changing the authorization engine, and amending the website coding so that if there were any issues with authorization responses in future, the site would not crash.
2) Another e-commerce site found that the performance issues that they were experiencing were due to database performance issues, while the web-server CPU usage was only at 25%, the backend db server CPU usage was 86%. Their solution was to upgrade the db server.
Therefore, it is necessary to use (install if necessary) performance monitoring tools to check each aspect of the website architecture during the execution phase.
<<<<<< =================== >>>>>>
Q.78: Could You Suggest an Execution Strategy for a Load Scenario?
Start with a test at 50% of the expected virtual user capacity for 15 minutes and a medium ramp rate. The different members of the team [testers will also need to be monitoring the CPU usage during the testing] should be able to check whether your website is handling the load efficiently or some resources are already showing high utilization.
After making any system adjustments, run the test again or proceed to 75% of expected load. Continue with the testing and proceed to 100%; then up to 150% of the expected load, while monitoring and making the necessary adjustments to your system as you go along.
<<<<<< =================== >>>>>>
Q.79: How To Report Load Testing Results?
Often the first indication that something is wrong is the end user response times start to climb. Knowing which pages are failing will help you narrow down where the problem is.
Whichever load test tool you use, it will need to produce reports that will highlight the following:
1) Page response time by load level
2) Completed and abandoned session by load level
3) Page views and page hits by load level
4) HTTP and network errors by load level
5) Concurrent user by minute
6) Missing links report, if applicable
7) Full detailed report which includes response time by page and by transaction, lost sales opportunities, analysis and recommendations
<<<<<< =================== >>>>>>
Q.80: What are the Important Aspects of Website Load Testing?
When testing websites, it is critically important to test from outside the firewall. In addition, web-based load testing services, based outside the firewall, can identify bottlenecks that are only found by testing in this manner.
Web-based stress testing of web sites is therefore more accurate when it comes to measuring a site's capacity constraints.
Web traffic is rarely uniformly distributed, and most Web sites exhibit very noticeable peaks in their volume patterns. Typically, there are a few points in time (one or two days out of the week, or a couple of hours each day) when the traffic to the Web site is highest.

No comments:

Post a Comment