For each Web traffic characteristic identified a more detailed description is given together with the implications for simulating the given characteristic within a load testing architecture.

1) User Equivalents, Connections or User Sessions

One of the main characteristics of Web Browser network traffic is the number of concurrent connections (TCP under HTTP) being processed at any given time. This characteristic is referred to as the number of concurrent connections or User Sessions (as a given number of users imply a given number of connections). Bradford and Crovella (1998) define the term User Equivalents as a characteristic that equates to some number of Web Browser users.

The idea of User Equivalents is to be able to characterize the Web Browser traffic as a population of a number of users. Performance requirements are typically documented in terms of numbers of users, i.e. The Web Server should support 1,000 concurrent users. For the purposes of Web Browser traffic load generation it is important, therefore, to be able to recreate such combinations of Web Server connections and requests that equate to a given number of users. Arlitt et al. (2001) use TCP connections and requests per second, on each connection, to represent User Equivalents, although Bradford and Crovella (1998) identify issues with over simplifying this relationship (these issues are discussed later in this Chapter).

The simulation of a given number of User Equivalents, with regards to TCP connections, involves translating the Web Browser activities to an overall strategy of connection handling. The connection strategy used by the Web Browser will vary depending upon HTTP version (HTTP 1.0 allows for many concurrent connections, whereas HTTP 1.1 mandates a maximum of 2 connections per server). For intranet activity, however, this HTTP 1.1 maximum is configurable, so in essence a maximum concurrent allowed variable exists and needs to be respected by the Web Browser (and Web Browser traffic load generators). This variation of TCP connections for each User Equivalent (HTTP 1.0 versus HTTP 1.1) has been researched and implemented into the HTTPERF Web Browser traffic load generator, Mosberger D. (1998).

In practice there are difficulties with recreating the connection strategy of multiple browsers. These issues include configurability (by individual) on number of concurrent connections that could be used, recreation of the Browser connection strategy for using multiple connections to retrieve Embedded References (.gifs etc) and the possible use of advanced HTTP features such as pipelining and look aheads.

Using Application Center Test a User is simulated via a Program Thread and on that thread connections are opened and requests are made on the open connection. Each ACT thread can have multiple connections Open but (unlike a real Web Browser) will Block on a single connection when a request is made. This simulation differs from a real Web Browser which would have multiple Open active connections per user but the pragmatic differences are small for performance verification.

Synthetic generators allow for the specification of the number of TCP Connections, as part of the workload definition.

2) Usage

The time of Day usage, Peaks and Troughs, characterization gives an idea of maximum usage. For Load Testing it is the Peak times and normal operation, that is typically simulated. This characteristic is easily simulated by load generators (including ACT) since the load levels are specified and these can be related to the time of day usage.

3) Aborted connections (User sessions) or Site Abandonment

This characteristic reflects the users tolerance for poor response times. That is after an eight second wait 10% of users might abort the transaction. The issue with simulating this characteristic is that often (as is the case with ACT) the request is made on a blocking socket. That is control only returns to the program after the request has been made or a TCP timeout has occurred. The TCP timeout defaults to 120 seconds so in practice it is difficult to abandon the request after a shorter interval. One solution would be to detect the actual response time then drop the remainder of the requests when a given threshold is reached although this is not the same as stopping after a given interval. Non-blocking load generators (e.g. HTTPERF) can implement a more realistic Site Abandonment behaviour.

4) Geographic distribution

The location of the end user, as well as the bandwidth available to the end user, are relevant characteristics for Web Application performance testing. Distance and bandwidth characteristics limit the arrival rate of the Web Traffic. Some Web traffic load generators use a technique called "bandwidth throttling" in order to restrict the bandwidth a given User Equivalent could use. In this way, even though the load generator is on a 100MB Lan, a user with a 128K DSL connection could be simulated. Application Center Test does not have this capability although (to some extent) the arrival rate could be constrained using other methods (see Requests per second and Wait Time characteristic below).

5) Client (IP) Request behaviour

The IP address of the HTTP Client could be relevant to a Web Server application if the IP is used for load balancing, security, or any other Client identification. Some Web Traffic generators provide an "IP Spoofing" feature whereby the IP of each User Equivalent could be unique. Application Center Test does not offer this capability, if a unique IP is required for each Virtual User then ACT cannot provide this requirement. To a certain extent ACT (and other web Traffic generators that do not support IP spoofing) could be used to drive the Web Traffic by placing multiple versions of the tool on different hosts.

6) Requests per Second

Along with Number of connections the Requests per Second (RPS) characteristic is the primary workload defining attribute for a Web traffic load generating tool. RPS can be defined for a single User Equivalent or for the population of User Equivalents within the load testing Scenario. If 100 users each make one request per second then the Scenario requests per second rate is 100. When specifying RPS it is important to define the rate against either User or Scenario. In both cases the RPS is governed by implementing program Waits or Sleep statements. So, if we had 100 User Equivalents and we specified 100 RPS for the Scenario then between each Request a Sleep or Wait for one second statement would be implemented. Sometimes the observed RPS is not as expected and this can be attributed to an overloading of the Web traffic generator host. As a rule the computer the Web traffic generator is executing on should not experience CPU utilization of greater than 80%. When the Web generator is itself stressed that at the least the RPS will not be as specified and at worst the test results could be invalid.

7) OFF Time, Wait Time or User Think Time

This is the time between URL requests. Bradford and Crovella (1998) identify two classes of OFF Time: Inactive and Active. Inactive OFF time is the time between Main Page requests (or User interaction) while Active OFF time is the time between Requests made by the Web Browser when retrieving Embedded References. Inactive OFF time is typically long while Active OFF time is short. Commercial tools such as LoadRunner from Mercury (www.mercury.com) Interactive allow for the definition of Inactive OFF time and call this characteristic User Think Time. Arlitt et al. (2001) refer to the Inactive OFF time characteristic as Inter-Request times within sessions, In this study the Inactive OFF time was observed as an average of 26 seconds.

Inactive OFF time needs to be variable for a given User Equivalent, to allow for different Web Browsing habits. Also the so called Active OFF times needs to be simulated, see Embedded Reference retrieval for further discussion on the impact of Active OFF times for load simulation.
For Application Center Test, all OFF Time is simulated via Sleep statements within the Virtual User scripts.

8) Embedded References

An Embedded Reference is a reference to a URL, within the Main Page being retrieved. For example if a web page (main Page) is being retrieved that has four images (.gif files) the Web Browser will retrieve the Main Page then, after realizing that other images\Embedded References are needed to display the full page, retrieve those (four) Embedded References. Embedded Reference retrieval increases the number of Requests per Second for each User Equivalent, during the time that the Embedded References are being retrieved. The retrieval of Embedded References also impacts the number of connections used by the Web Browser. Typically the Web Browser will open other connections to retrieve Embedded References as well as make multiple requests on the same connection (that is make the connection persistent).

Application Center Test (ACT) can reuse a connection for a Request (i.e. implement persistent connections) but cannot block on multiple connections within a single User thread. This means that the User Equivalent in ACT does not use the same connection strategy, as a real Web Browser, for retrieving Embedded References.

9) Concentration of References

The percentage of the time a given URL is retrieved is part of an overall pattern of access characteristic. These access patterns are of interest for simulation as they are relevant to caching (either by the Web Browser, web server or Proxy intermediary). Application Center Test (ACT) can reproduce any desired access pattern since the URLs being retrieved are individually specified. Note: with ACT (and many other Web Traffic Generators) the HTTP Headers need to specified in such a way as to simulate the access relationship the Client has with the URL being requested. In this way, for example, a first time request can be differentiated from a subsequent request.

10) Response code

For an individual application the Response code could be predetermined, for example File Not Found should be predictable if the URLs are specified. This characteristic is, however, included in the general Web Traffic characterization because over a given sample a percentage of each Response code was found. ACT can induce any response code by predetermining the availability of URL requested.

11) File type

Similar to the Response code characteristic, the File type (of the URL) can be predetermined by a Web Traffic Generator, including ACT.

12) Mean transfer size

This characteristic is relevant for caching and Network bandwidth.
For Synthetic HTTP load generators this characteristic could be defined as part of the workload specification.
For Application specific HTTP load generators this characteristic is not defined as part of the workload specification as it is inherent in the specification of the HTTP Requests (URLs).

13) Size distribution

As for Mean transfer size.

14) Temporal locality

This characteristic is of special interest to cache design\considerations. Considerations for HTTP load generation are similar to the Mean transfer size characteristic.