Skip to main content

How to Understand LoadRunner Report

By
Web Resource Monitors



You obtain information about the performance of your Web server using
LoadRunner’s Web Resource monitor.
 
This chapter includes:
➤ About Web Resource Monitoring on page 
➤ Hits per Second Graph on page 
➤ Throughput Graph on page 
➤ HTTP Responses per Second Graph on page 
➤ Pages Downloaded per Second Graph on page 
➤ Retries per Second Graph on page 
➤ Connections Graph on page 
➤ Connections per Second Graph on page 
➤ SSLs per Second Graph on page


About Web Resource Monitoring
The Web Resource monitor enables you to analyze the throughput on the
Web server, the number of hits per second that occurred during the
scenario, the number of HTTP responses per second, the HTTP status codes
(which indicate the status of HTTP requests, for example, the request was
successful, the page was not found) returned from the Web server, the
number of downloaded pages per second, the number of server retries per
second, the number of open TCP/IP connections, the number of new TCP/IP
connections per second, and the number of SSL Connections per second.
Hits per Second Graph
The Hits Per Second graph shows the number of hits (HTTP requests) to the
Web server (y-axis) as a function of the elapsed time in the scenario (x-axis).
This graph can display the whole step, or the last 60, 180, 600, or 3600
seconds. You can compare this graph to the Transaction Response Time
graph to see how the number of hits affects transaction performance.
Throughput Graph
The Throughput graph shows the amount of throughput on the Web server
(y-axis) during each second of the scenario run (x-axis). Throughput is
measured in bytes and represents the amount of data that the Vusers
received from the server at any given second. You can compare this graph to
the Transaction Response Time graph to see how the throughput affects
transaction performance.
In the following example, the Transaction Response time graph is compared
with the Throughput graph. It is apparent from the graph that as the
throughput decreases, the transaction response time also decreases. The
peak throughput occurred at approximately 1 minute into the step. The
highest response time also occurred at this time.




Retries per Second Graph


The Retries Per Second graph shows the number of attempted Web server
connections (y-axis) as a function of the elapsed time in the scenario (x-
axis). A server connection is retried when the initial connection was
unauthorized, when proxy authentication is required, when the initial
connection was closed by the server, when the initial connection to the
server could not be made, or when the server was initially unable to resolve
the load generator’s IP address.


Connections Graph


The Connections graph shows the number of open TCP/IP connections (y-
axis) at each point in time of the scenario (x-axis). One HTML page may
cause the browser to open several connections, when links on the page go to
different Web addresses. Two connections are opened for each Web server.


This graph is useful in indicating when additional connections are needed.
For example, if the number of connections reaches a plateau, and the
transaction response time increases sharply, adding connections would
probably cause a dramatic improvement in performance (reduction in the
transaction response time).


Connections per Second Graph


The Connections Per Second graph shows the number of new TCP/IP
connections (y-axis) opened and the number of connections that are shut
down each second of the scenario (x-axis).


This number should be a small fraction of the number of hits per second,
because new TCP/IP connections are very expensive in terms of server,
router and network resource consumption. Ideally, many HTTP requests
should use the same connection, instead of opening a new connection for
each request.








SSLs per Second Graph


The SSLs per Second graph shows the number of new and reused SSL
Connections (y-axis) opened in each second of the scenario (x-axis). An SSL
connection is opened by the browser after a TCP/IP connection has been
opened to a secure server.


Because creating a new SSL connection entails heavy resource consumption,
you should try to open as few new SSL connections as possible; once you’ve
established an SSL connection, you should reuse it. There should be no
more than one new SSL connection per Vuser.


If you set your run-time settings to simulate a new Vuser at each iteration
(via the Browser Emulation tab in the Run-Time Settings menu), you should
have no more than one new SSL connection per Vuser per iteration. Ideally,
you should have very few new TCP/IP and SSL connections each second.

Comments

Post a Comment

Popular posts from this blog

Steps To Hunt the Bugs Successfully

By
The testers should catch the bugs in software that they’re testing. Testers should try to catch as several vital bugs as soon as possible. Catching the crucial bug earlier on Product-Life-Cycle can save the Projects from financial losses & mitigate the risks as compared for catching the same at a later stage in SDLC. Steps to hunt the bugs: Sometimes it’s useful to break the rules: The following test cases, which were predefined a tester can miss the bugs so it makes it impossible’s to provide the product i.e. 100 percent bug free. If you-follow pre-determined test cases you risks becoming blind to outside the bugs. A first secret is to check the functionality under the test. It’ll be an effective channel to discover the more bugs, because functionality is not generally covered by the test cases. Examine the patterns: You might have noticed that the bugs can be often met in the groups, one can call them-gregarious. The testing a new but the similar functionality...
Post a Comment
Read more

Cross browser testing Tools

By
Cross Browser testing It is a process to test the web apps across multiple browsers. It involves the checking compatibility of the app across multiple web browsers & ensures that your web app’s works correctly across different web browsers. Tools for Cross Browser Testing Browser shots: The browser shots might be most exhaustive cross browser-testing tool that exists. Browser Shots includes all of most popular-browsers, like Firefox, Chrome, & Safari, along with the tons of another browser’s that might sound unfamiliar, like Sea Monkey, Flock, & Iceape. You can adjust the resolution, color-settings, & even Flash and JavaScript settings. Cross Browser Testing: It allows users to test their websites with over the hundred resolution or browser and Operating System combinations. This also has support to mobile web-browsers, which is crucial because the web traffic is making shift from the primarily desktop computer users to primarily mobile ...
Post a Comment
Read more

Mobile Application Testing: Strategy for Development

By
There are a huge number of demands and lots of competitions in the mobile application industries. In that demands and competitions, the mobile application testing has become more important. The testing phase of the mobile application testing looks like evil between the creative process and excitement of new products in the market. According to the survey, “In US, on an average 2-3 hours per day people spends their time on smartphones and tablets. On that time, they spent 80% on mobile application and remaining 20% on web applications.” Few list of key factors for successful mobile application testing strategies are: Selection of Device for Testing : Before introducing the mobile application test activities, first select the devices for testing the application. Selection decision is very important because only devices can help to targets maximum numbers of the customers for accessing the application. There are two parts for device selection: §   Device Model ...
Post a Comment
Read more