Client Profiles Protocol Version Fields

Use the Protocol Version fields in the HTTP: Browser area of the Client Profiles tab to define the HTTP protocol functionality for a test, whether connections are kept open, the rates at which connections are processed, as well as HTTP pipelining.

TIP: If you select a default browser in the Preload Values From field, associated default values appear in the applicable fields.

TIP: See HTTP example test scenarios for the client and server behavior that is a result of various client Protocol Version field parameter settings.

Field

Description

Connection/Rate Fields:

Maximum Connections per Server

Enter the maximum number of connections allowed per server for this user profile. The number of connections to a server, depends on the Persistence connection or level-2 URL. Example

Unlimited Maximum Connections per SimUser

Allows an unlimited number of connections. Deselect the checkbox if you want to set a maximum value in the Maximum Connections per SimUser field.

Maximum Connections per SimUser

Limits the total number of connections per SimUser to the number that you enter here, regardless of how many servers are in the Action list. You must deselect the Unlimited Maximum Connections per SimUser checkbox before you can enter a value (greater than 0) in this field. For example, If there are 8 servers in the Action list, and the Maximum Connections Per Server field is set to 2, the result would be 16 maximum connections. However, if you enter 10 in the Maximum Connections per SimUser field, then only the first 5 servers in the Action list would be used.

Maximum Requests per Connection

When you enable HTTP/1.0 with Keep Alive or HTTP/1.1 with Persistence, and use the same IP address or fully qualified domain name (FQDN) multiple times in the Action list, you can specify a Maximum Requests per Connection value. This value defines the maximum number of HTTP requests to send over the TCP connection (for the same IP address or FQDN) before closing the connection. Examples

NOTE: If you are running a Device test (emulated client and server), you should also configure the Avalanche server to enable HTTP/1.0 with Keep Alive or HTTP/1.1 Persistence.

Protocol Version Fields:

HTTP/1.0

HTTP/1.1

Keep Alive

Persistence

You can select a protocol version for each profile:

HTTP/1.0 (without Keep Alive): Activates the standard features of version 1.0.
Keep Alive: Activates the Keep Alive feature, which keeps the connection open after the initial request is accepted.
HTTP/1.1 (without Persistence): Activates the standard features of version 1.1.
Persistence: Allows persistent connections so that multiple requests can use the same connection. Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling takes place using the Connection header field. After a close is signaled, the client MUST NOT send any more requests on that connection. With a Non-Persistence connection, in a normal HTTP (or database connection), after the server has sent a reply, it shuts down the TCPIP connection.

NOTE: Do not check the Persistence checkbox if persistence is enabled in the Proxy area on the Client Profiles tab.

The protocol selected does not have to match the version on the servers/devices under test, but HTTP/1.1 is recommended because many devices (servers, load balancers) rely on the Host: www.somewebsite.com string in the header field to determine the server to which to route a request.

Both HTTP/1.0 with Keep Alive enabled and HTTP/1.1 with Persistence mode simulate a user issuing multiple GETs to one server to retrieve multiple objects using the same TCP connection. To use Keep Alive or Persistence, you must have multiple URLs accessing the same server. Example

HTTP Pipelining Fields:

Enable

Select to generate multiple HTTP requests to a single socket on a persistent connection, without waiting for the corresponding responses. HTTP pipelining reduces network load by allowing fewer TCP packets to be sent over the network.

NOTES:

Avalanche supports HTTP pipelining for HTTP/1.1 only. You must also select the Persistence checkbox for HTTP/1.1.
The HTTP server must also conform to HTTP/1.1 to support HTTP pipelining. The server is not required to pipeline responses, but it must be able to handle pipelined requests from a client.
If you enable this field, you must also configure HTTP Pipelining settings in your Action list, or pipelining will not occur.

Proxy Pipelining

Select to indicate that the proxy server supports pipelining.

Max. Requests

The number of requests to be pipelined at one time, from two (2) to 128, inclusive. The default value is two (2). Avalanche continues to add more requests into one TCP packet until one of the following conditions is met:

The number of assembled requests reaches the maximum number of pipelined requests that you configure in this field.
The sum of the length of the current pipelined requests and the subsequent requests exceeds the maximum length of one TCP packet, as configured in the Client Network tab, Maximum Segment Size field (MSS).

For example, if you configure 10 maximum requests, and you have 7 total requests in your pipelined group whose total length is not greater than the MSS, then all 7 requests will be assembled into one TCP packet and sent. However, if the length of the first 3 requests is less than the MSS, but the length of the first 4 requests exceeds the MSS, then only the first 3 requests will be assembled into one TCP packet and sent. Avalanche then performs the same condition checks as described above for assembling the remaining requests.

NOTE: If the length of one HTTP request is equal to or greater than the MSS, then it will be sent as if pipelining is not configured, and the request will not be included in the pipelining statistics, even if it is included in the pipelined group.

HTTP Request Field:

Compress HTTP Request

Select if you want the HTTP POST and PUT request bodies, referenced in your Actions list, compressed into a gzip format. POST and PUT request actions that contain HTTP body data (that is, data after the HTTP headers) will have the “Content-Encoding: gzip” header added, and the body of the request will be compressed using the gzip compression method. If you have enabled HTTP Chunked Transfer Coding, the body is first compressed and then chunk coded.

Related Information:

Setting Protocol Version

Emulating a Browser

HTTP Pipelining

Configuring a Client Profile

HTTP Test Scenario Overview