| Measurement |
Description |
Measurement Unit |
Interpretation |
| Requests_sec |
Indicates the rate at which HTTP requests were received. |
Number/Sec |
These measures are effective indicators of the workload on the NetScaler device. You can even compare the values of these measures to determine whether/not all requests have been responded to. Request processing bottlenecks can thus be isolated. |
| Total_requests |
Indicates the total number of HTTP requests (inclusive of HTTP v1.0 requests and HTTP v1.1 requests) that were received during the last measurement period. |
Number |
| Responses_sec |
Indicates the rate at which HTTP responses were received. |
Number/Sec |
| Total_responses |
Indicates the total number of HTTP responses (inclusive of HTTP v 1.0 and HTTP v 1.1 responses) that were received during the last measurement period. |
Number |
| Gets_requests |
Indicates the number of HTTP requests that were received using the GET method during the last measurement period. |
Number |
|
| Pct_gets_requests |
Indicates the percentage of HTTP requests received using the GET method during the last measurement period. |
Percent |
|
| Posts_requests |
Indicates the number of HTTP requests that were received using the POST method during the last measurement period. |
Number |
|
| Pct_posts_requests |
Indicates the percentage of HTTP requests received using the POST method during the last measurement period. |
Percent |
|
| Other_requests |
Indicates the number of HTTP requests that were received using methods other than GET and POST during the last measurement period. |
Number |
Some of the well-defined HTTP methods are HEAD, PUT, DELETE, OPTIONS, and TRACE. User-defined methods are also counted. |
| Pct_others_requests |
Indicates the percentage of HTTP requests received other than the GET and POST methods during the last measurement period. |
Percent |
| Http10_requests |
Indicates the number of HTTP v 1.0 requests received by the NetScaler device during the last measurement period. |
Number |
Since HTTP 1.0 connections are not capable of providing information about the client's ability to accept compressed data, which is one of the features of the NetScaler devices, it is important to be able to monitor the number of HTTP 1.0 connections relative to the the total connections.
By comparing the values of these two measures, you can determine whether/not all HTTP/1.0 requests have been responded to by the NetScaler appliance. |
| Http10_responses |
Indicates the total number of HTTP v 1.0 responses that were sent during the last measurement period. |
Number |
| Http11_requests |
Indicates the number of HTTP v 1.1 requests received by the NetScaler device during the last measurement period. |
Number |
By comparing the values of these two measures, you can determine whether/not all HTTP/1.1 requests have been responded to by the NetScaler appliance. |
| Http11_responses |
Indicates the total number of HTTP v 1.1 responses that were sent during the last measurement period. |
Number |
| Content_len_req |
Indicates the number of HTTP requests with the Content-length field of the HTTP header set during the last measurement period. |
Number |
NetScaler compression module treats server response as a data stream. It accumulates server response packets until certain conditions are met. Whence the conditions are met, a batch job would be triggered to compress the accumulated data and the compressed data would be output subsequently.
For a server response that only triggers a single batch job, NetScaler would output a Content-length response. This is same for both HTTP 1.0 and 1.1 client types.
When an HTTP client is reading a response message from a server or when an HTTP server is reading a request from a client, the client/server (as the case may be) needs to know when it has reached the end of the message. This is particularly important with persistent (keep alive) connections, because a connection can only be re-used by another HTTP transaction after the request message has been read and the response message has been fully received. One of the ways by which the HTTP client/server indicates the end of a request/response message is by using the Content-Length Header. The length of the content after the request/response headers can be specified in bytes with the Content-Length header.
Using the values of these measures, you can figure out how many large requests were processed and responded to by the NetScaler device, and thus assess the workload on the device. |
| Content_len_res |
Indicates the number of HTTP responses that were sent with the Content-length field of the HTTP header set during the last measurement period. |
Number |
| Pct_content_len_res |
Indicates the percentage of responses sent out by the NetScaler device with the Content-length field of the HTTP response header set. |
Percent |
| Chunked_requests |
Indicates the number of HTTP requests with the Transfer-Encoding field of the HTTP header set to chunked during the last measurement period. |
Number |
When an HTTP client is reading a response message from a server or when an HTTP server is reading a request from a client, the client/server (as the case may be) needs to know when it has reached the end of the message. This is particularly important with persistent (keep alive) connections, because a connection can only be re-used by another HTTP transaction after the request message has been read and the response message has been fully received. One of the ways by which the HTTP client/server indicates the end of a request/response message is by using Chunked Encoding. Chunked encoding allows HTTP messages to be broken up into several parts. Chunking is most often used by the server for responses, but clients can also chunk large requests. If the Transfer-Encoding field of an HTTP request/response is set to chunked, then the client/server (as the case may be) starts sending the HTTP request/response before knowing its total length. The client/server then breaks the request/response into chunks and sends them in sequence, inserting the length of each chunk before the actual data. The message ends with a chunk of size zero.
Using the values of these measures, you can figure out how many large requests were processed and responded to by the NetScaler device, and thus assess the workload on the device. |
| Chunked_responses |
Indicates the number of HTTP responses that were sent with the Transfer-Encoding field of the HTTP header set to chunked during the last measurement period. |
Number |
| Pct_chunked_res |
Indicates the percentage of HTTP responses that were sent with the Transfer-Encoding field of the HTTP header set to chunked during the last measurement period. |
Percent |
| Multipart_responses |
Indicates the number of HTTP multi-part responses sent during the last measurement period. |
Number |
In multi-part responses, one or more entities are encapsulated within the body of a single message. |
| Pct_multipart_res |
Indicates the percentage of HTTP multi-part responses that were sent during the last measurement period. |
Percent |
| Fin_term_responses |
Indicates the number of FIN-terminated responses sent during the last measurement period. |
Number |
In FIN-terminated responses, the server finishes sending the data and closes the connection. For large server response (or any other condition) that would trigger multiple compression batch jobs, NetScaler would output FIN terminated response without Content-Length header (RFC compliant). Because compression is performed on batch basis, NetScaler can't determine length of compressed data until the last batch is done. Using FIN-terminated response, instead of chunked encoding, maximizes NetScaler's compatibility with HTTP 1.0 client. |
| Pct_fin_res |
Indicates the percentage of FIN-terminated responses that were sent during the last measurement period. |
Percent |
| Req_data_received |
Indicates the amount of HTTP data received during the last measurement period. |
MB |
|
| req_data_transmit |
Indicates the amount of HTTP data transmitted during the last measurement period. |
MB |
|
| Response_data_received |
Indicates the amount of data received as responses during the last measurement period. |
MB |
|
| Response_data_transmit |
Indicates the amount of data sent as responses during the last measurement period. |
MB |
|
| Incomplete_headers |
Indicates the total number of HTTP requests and responses that were received with the HTTP header spanning more than one packet during the last measurement period. |
Number |
Ideally, the value of this measure should be 0. A high value for this measure may warrant an investigation. You may begin your investigation by determining the type of headers that were incomplete most often - the request headers or response headers? For this, compare the values of the Incomplete_req_headers and Incomplete_res_headers measures. |
| Incomplete_req_headers |
Indicates the number of HTTP requests that were received with the HTTP header spanning more than one packet during the last measurement period. |
Number |
| Incomplete_res_headers |
Indicates the number of HTTP responses that were sent with the HTTP header spanning more than one packet during the last measurement period. |
Number |
| Http_500_server |
Indicates the current status of HTTP responses received from the NetScaler appliance. |
|
Response status codes beginning with the digit “5” indicate cases in which the HTTP server - in this case, the NetScaler appliance - is aware that it has encountered an error or is otherwise incapable of performing the request. |
| Invalid_messages |
Indicates the number of large or invalid requests and responses received during the last measurement period. |
Number |
Ideally, the values of these measures should be 0. |
| Invalid_chunk_req |
Indicates the large or invalid requests received in which the Transfer-Encoding field of the HTTP header has been set to chunked. |
Number |
| Invalid_content_len |
Large or invalid requests received in which the Content-length field of the HTTP header has been set. |
Number |