Web resource monitor graphs

This section describes the Web Resource monitor graphs that enable you to analyze resources on the web server during a performance test run.

In this topic:

Bytes Sent per Second graph

The Bytes Sent per Second graph shows the rate at which the data bytes are sent by the Web service.

Back to top

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 performance test (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.

Back to top

Throughput graph

The Throughput graph shows the amount of throughput (y-axis) on the web server during each second of the test 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.

Back to top

HTTP Responses per Second graph

The HTTP Responses per Second graph shows the number of HTTP status codes in the y-axis. The codes indicate the status of HTTP requests, for example, "the request was successful" or "the page was not found". The x-axis displays the HTTP responses returned from the web server during each second of the performance test run .

The HTTP responses are grouped by status code. You can also group the results shown in this graph by script (using the "Group By" function) to locate scripts which generated error codes.

The following table displays a list of HTTP status codes that appear in the HTTP Responses per Second Graph.

Code	Description	Code	Description
200	OK	405	Method Not Allowed
201	Created	406	Not Acceptable
202	Accepted	407	Proxy Authentication Required
203	Non-Authoritative Information	408	Request Timeout
204	No content	409	Conflict
205	Reset content	410	Gone
206	Partial content	411	Length Required
300	Multiple Choices	412	Precondition Failed
301	Moved Permanently	413	Request Entity Too Large
302	Found	414	Request - URI Too Large
303	See Other	415	Unsupported Media Type
304	Not Modified	416	Requested range not satisfiable
305	Use Proxy	417	Expectation Failed
307	Temporary Redirect	500	Internal Server Error
400	Bad Request	501	Not Implemented
401	Unauthorized	502	Bad Gateway
402	Payment Required	503	Service Unavailable
403	Forbidden	504	Gateway Timeout
404	Not Found	505	HTTP Version not supported

Back to top

Pages Downloaded per Second graph

The Pages Downloaded per Second graph shows the number of Web pages (y-axis) downloaded from the server during each second of the test run (x-axis). This graph helps you evaluate the amount of load Vusers generate, in terms of the number of pages downloaded.

Like throughput, downloaded pages per second is a representation of the amount of data that the Vusers received from the server at any given second.

• The Throughput graph takes into account each resource and its size (for example, the size of each .gif file, the size of each Web page).

• The Pages Downloaded per Second graph takes into account simply the number of pages.

In the following example, the Throughput graph is compared with the Pages Downloaded per Second graph. It is apparent from the graph that throughput is not proportional to the number of pages downloaded per second. For example, between 15 and 16 seconds into the performance test, the throughput decreased while the number of pages downloaded per second increased.

Back to top

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 performance test (x-axis).

A server connection is retried when:

• The initial connection was unauthorized

• Proxy authentication is required

• The initial connection was closed by the server

• The initial connection to the server could not be made

• The server was initially unable to resolve the load generator's IP address

Back to top

Connections graph

The Connections graph shows the number of open TCP/IP connections (y-axis) at each point in time of the performance test (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).

Back to top

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 performance test (x-axis).

This number should be a small fraction of the number of hits per second, because new TCP/IP connections are 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.

Back to top

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 performance test (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, try to open as few new SSL connections as possible, and reuse any established SSL connections. Avoid having more than one new SSL connection per Vuser.

If you set your runtime settings to simulate a new Vuser at each iteration (using the runtime settings Browser Emulation node), you should have no more than one new SSL connection per Vuser per iteration. Ideally, you should have few new TCP/IP and SSL connections each second.

Back to top

WebSocket Statistics graph

This WebSocket statistics graph shows WebSocket statistics during the run.

Back to top

See also:

• Monitors
• Create test assets
• Design a test