Home · Search · Print · Help 

Here is SrvLB-L7-4 at a glance.

Workload Name:	SrvLB-L7-4
Polygraph Version:	2.6
Configuration:	workloads/srvlb-l7-4.pg (under development)
Parameters:	peak request rate
How-Tos:	TBA
Results:	TBA
Synopsis:	workload for testing layer 7 server load balancers.

1. Background
2. Feature overview
3. Details
    3.1  Phase schedule
    3.2  Servers configuration
    3.3  Robots configuration
    3.4  Content types
    3.5 WAN latency and packet loss
4. Parameters
    4.1 Peak Request Rate
    4.2 Bench IP Addresses
    4.3 Bench Address Masks

1. Background

The SrvLB-L7-4 workload is designed to test devices like Layer 7 server load-balancing switches. This workload is similar to SrvLb-L4-4 (its layer 4 counterpart) but has features for testing layer 7 capabilities of load balancers.

SrvLB-L7-4 includes 3 kinds of origin servers that differ in hosted content. A load balancer under test has to direct requests to correct servers while sustaining peak request rate. At least two instances of each server type are provided to test load balancing abilities in addition to basic L7 redirection.

2. Feature overview

The SrvLB-L7 environment models many key Web traffic characteristics, including the following.

• a mixture of content types
• varying offered load, depending on the test phase
• a working set of URLs that changes its content with time but can preserve its size
• all distributed clients can share information about the global URL set
• hot subsets simulating flash crowds
• virtually infinite number of different objects that are added to the working set as needed
• object life-cycles (expiration and last-modification times)
• persistent connections
• network packet loss
• reply sizes
• server-side latencies
• a mixture of cache hits and cache misses
• a mixture of cachable and uncachable responses
• object popularity (recurrence)
• request rates and interarrival times
• embedded objects and browser behavior
• cache validation (IMS requests)
• forced cache validations (reloads)

3. Details

3.1 Phase schedule

The workload schedule consists of 3 phases. The schedule includes 3 phases with time-based goals. The total test duration (based on the time-based goals) is about 2.50hour.

Phase	Factors (%)						Other
	Populus		Recurrence		Special Msgs
	beg	end	beg	end	beg	end
ramp	1	100	100	100	100	100
plat	100	100	100	100	100	100
exit	100	1	100	100	100	100

Phase "ramp" lasts for 30.00min. During this phase, the robot population size increases from 1.00% to 100.00%. The offered per-robot load remains stable at 100.00% of its peak level. The recurrence level remains stable at 100.00% of robot recurrence ratios. The portion of special messages remains stable at 100.00%.

Phase "plat" lasts for 1.50hour. During this phase, the robot population size remains stable at 100.00% of its peak level. The offered per-robot load remains stable at 100.00% of its peak level. The recurrence level remains stable at 100.00% of robot recurrence ratios. The portion of special messages remains stable at 100.00%.

Phase "exit" lasts for 30.00min. During this phase, the robot population size decreases from 100.00% to 1.00%. The offered per-robot load remains stable at 100.00% of its peak level. The recurrence level remains stable at 100.00% of robot recurrence ratios. The portion of special messages remains stable at 100.00%.

3.2 Servers configuration

The workload defines 3 server types.

Server "SrvLb-L7-4" hosts the following 3 content types: "HTML" (68.18% of all hosted content), "download" (2.27%), and "other" (29.55%). The following 3 content types can be accessed directly: "HTML", "download", and "other". Server "think time" distribution is set to norm(150msec, 50msec). This server uses persistent connections. The number of transactions per connection is distributed as zipf(64). Idle persistent connections are closed after a 15.00sec timeout. Only basic reply types are used.

Server "SrvLb-L7-4" hosts the following 2 content types: "image" (90.91% of all hosted content) and "other" (9.09%). The following 2 content types can be accessed directly: "image" and "other". Server "think time" distribution is set to norm(150msec, 50msec). This server uses persistent connections. The number of transactions per connection is distributed as zipf(64). Idle persistent connections are closed after a 15.00sec timeout. Only basic reply types are used.

Server "SrvLb-L7-4" hosts the following 2 content types: "image" (90.91% of all hosted content) and "other" (9.09%). The following 2 content types can be accessed directly: "image" and "other". Server "think time" distribution is set to norm(150msec, 50msec). This server uses persistent connections. The number of transactions per connection is distributed as zipf(64). Idle persistent connections are closed after a 15.00sec timeout. Only basic reply types are used.

3.3 Robots configuration

The workload defines 1 robot type.

Robot "SrvLb-L7-4-Clt" is a "constant request rate" robot with request rate of 0.70 requests per second. About 95.00% of requests refer to URLs in a globally shared, public working set. This robot revisits 95.00% of previously requested URLs (offering a hit when a URL is cachable). About 100.00% of embedded objects will be loaded.

This robot is not allowed to open more than 4 connections at any given time, even if that limit causes request rate decrease or memory exhaustion. Moreover, waiting transaction queue can grow without bounds. Robot's private cache is limited to 1000 entries. This robot uses persistent connections. The number of transactions per connection is distributed as zipf(16). Idle persistent connections are never closed by this robot. The following 3 request types are used: "IMS" (10.00% of all possible request types), "Reload" (5.00%), and "Basic" (85.00%).

"SrvLb-L7-4-Clt" robots direct 10.00% of all requests to 1.00% of the working set, using popUnif() popularity distribution.

3.4 Content types

The workload uses 4 unique content types.

Type	Reply Size	Cachability	Extensions
HTML	exp(8.500KB)	90.00%	.html and .htm
download	logn(300.000KB, 300.000KB)	95.00%	.exe, .zip, and .gz
other	logn(25.000KB, 10.000KB)	72.00%
image	exp(4.500KB)	80.00%	.png

The size distribution for "HTML" content type is exp(8.500KB). About 90.00% of "HTML" objects are cachable. This content type is a container. Objects may contain (embed) the following 2 content types: "image" (50.00% of all embedded content) and "image" (50.00%). The number of embedded objects per container is distributed as zipf(13). The following 2 extensions may appear at the end of URLs: ".html" and ".htm".

The size distribution for "download" content type is logn(300.000KB, 300.000KB). About 95.00% of "download" objects are cachable. This content type does not contain other types. The following 3 extensions may appear at the end of URLs: ".exe", ".zip", and ".gz".

The size distribution for "other" content type is logn(25.000KB, 10.000KB). About 72.00% of "other" objects are cachable. This content type does not contain other types.

The size distribution for "image" content type is exp(4.500KB). About 80.00% of "image" objects are cachable. This content type does not contain other types. The following 1 extension may appear at the end of URLs: ".png".

3.5 WAN latency and packet loss

For SrvLB-L7 tests, Polygraph client machines are configured to use FreeBSD's DummyNet feature.

We configure Polygraph clients with 100 millisecond delays (per packet, incoming and outgoing), and with a 0.1% probability of dropping a packet. Server think times are normally distributed with a 150msec mean and a 50msec standard deviation. Note that the server think time does not depend on the oid. Instead, it is randomly chosen for every request.

We do not add packet delays or packet loss on Polygraph servers.

4. Parameters

Here is an explanation of some of the workload parameters.

4.1 Peak Request Rate

This parameter specifies the request rate for the Plateau phase of the test.

4.2 Bench IP Addresses

The primary IP addresses of physical hosts running Polygraph are set in the workload file. The number of machines determines the maximum request rate that a test can generate.

4.3 Bench Address Masks

The address mask settings affect the aliases created by Polygraph. Polygraph robots bind to the created aliases at the beginning of the test. Default address masks are just fine unless they conflict with other bench IP addresses.

Here is a sample workload configuration.

Bench TheBench = {
            client_side = {
        addr_mask = 'lo0::10.44.0.0';  // aliases use 10.X/16 network
        hosts = [ '172.16.44.61-70' ]; // real IPs use 172.16/16
    };
    server_side = {
        addr_mask = '172.16.44.0:80';
        hosts = ['172.16.44.191-200'];
    };
    // maximum rate given the number of hosts above
    peak_req_rate =
        client_side.max_host_load * count(client_side.hosts);
};

Home · Search · Print · Help