Thursday, 29 September 2011

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.

0 comments:

Post a Comment

Bookmark Us

Delicious Digg Facebook Favorites More Stumbleupon Twitter