NetScaler HTTP Test

These measures are effective indicators of the workload on the ADC 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.

Some of the well-defined HTTP methods are HEAD, PUT, DELETE, OPTIONS, and TRACE. User-defined methods are also counted.

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 ADC devices, it is important to be able to monitor the number of HTTP 1.0 connections relative to 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 ADC appliance.

By comparing the values of these two measures, you can determine whether/not all HTTP/1.1 requests have been responded to by the ADC appliance.

ADC 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, ADC 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 ADC device, and thus assess the workload on the device.

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 ADC device, and thus assess the workload on the device.

In multi-part responses, one or more entities are encapsulated within the body of a single message.

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, ADC would output FIN terminated response without Content-Length header (RFC compliant). Because compression is performed on batch basis, ADC can’t determine length of compressed data until the last batch is done. Using FIN-terminated response, instead of chunked encoding, maximizes ADC’s compatibility with HTTP 1.0 client.

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 request headers and Incomplete response headers measures.

Response status codes beginning with the digit "5" indicate cases in which the HTTP server - in this case. the ADC appliance - is aware that it has encountered an error or is otherwise incapable of performing the request. 

Ideally, the values of these measures should be 0.

Ideally, the values of these measures should be 0.

SPDY (pronounced "speedy") is a deprecated open-specification communication protocol that was developed primarily at Google for transporting web content. SPDY manipulates HTTP traffic, with particular goals of reducing web page load latency and improving web security. SPDY achieves reduced latency through compression, multiplexing, and prioritization, although this depends on a combination of network and website deployment conditions.