| Field |
Description |
Select a Load Profile |
Select a load profile or use the buttons
in the pane to create, copy, rename, or delete a profile. |
| General
Fields: |
Specification |
Select the type of traffic that is measured for the load.
NOTES:
- When using the Bandwidth
traffic type, you should configure user-based
load profiles instead of global
load profiles. With user-based load profiles,
the load generator has better control to achieve the
desired bandwidth. If the desired bandwidth is nearly
line-rate, it is best to configure a load constraint
for Maximum
Living SimUsers to suppress a burst of Simusers
and maintain precise load control.
- For all
user-based load profiles, you must select the same traffic type
from the following list of those supported:
- Bandwidth
- SimUsers, SimUsers/second, or SimUsers/hour
- Connections/second
- Transactions/second
- The resolution of the load generated is best
effort only. The generated load is accurate,
provided an integral multiplier is used. If you configure
a load that uses a decimal multiplier, it may not
yield the results expected. (For example, 5400 SimUsers/hour
may not yield 1.5 SimUsers/second.) Thus, you should
configure the load such that an integral multiplier
is used, or use a .../second load specification for
more predictable results.
|
| Traffic type |
Description |
| Bandwidth |
Specifies the amount of data that can be transmitted
in a fixed amount of time over all combined interfaces.
Bandwidth is usually expressed in kilobits per second
( Kbps). |
| BodyBytes |
Generates HTTP requests
that solicit HTTP response
bodies of the specified length from the simulated server
and should be complemented with load constraints. The
BodyBytes load type only
applies when using a simulated server. |
| Connections |
Denotes a TCP connection.
Defines the number of simultaneous network connections
initiated from Avalanche. This setting generates enough
load to reach and sustain the desired number of open TCP connections.
You can use this load specification with any TCP connection-based protocol including HTTP, FTP, and
SMTP. Open TCP
connections depend on the connection establishment rate,
system efficiency, and user behavior, such as Think Time.
Specifying the same number of TCP
connections on different systems does not mean the traffic
generated will be the same.
An open connection does not necessarily have nonstop
activity. Pay attention to the time it takes a TCP connection to complete, the time to SYN/ ACK, and the
number of successful versus failed transactions at a specified
number of open TCP connections. |
| Connections/second or Connections/hour |
This load specification is often preferred by network
equipment manufacturers for testing network devices. One
TCP connection can contain up
to hundreds of transactions, depending on client profile
configuration and server response.
While the basic unit of load generated is SimUsers,
Avalanche calculates this load type based on historical
data. Avalanche dynamically adjusts the rate of user arrival
(as in SimUsers/second or SimUsers/hour) to match the
targeted connections/second or connections/hour rate. |
| SimUsers |
An abbreviation for simulated or virtual users.
SimUser applies to a user processing through an Actions
list one time. This load specification generates enough
load to reach and maintain a target number of concurrent
simulated users. It allows you to determine the maximum
number of concurrent users your device, infrastructure,
or system can handle.
Use this specification if you want to keep applying
load even after the device under test fails. The amount
of traffic generated depends on the performance of the
device under test. As the system slows down due to overloading,
generally each user takes longer to process through the
Actions list, and the load "throttles back"
and generates fewer new users. |
| SimUsers/second or SimUsers/hour |
Maintains a target number of concurrent simulated users
per second or hour, and provides a more realistic simulation
of users generating traffic on a system. The load specification
helps you identify where the system breaks down because
the load may ramp up too quickly and will not "throttle
back," but will continue independently of the behavior
of the device tested. |
| Transactions |
Defines the number of simultaneous transactions
generated. This specification generates and maintains
enough load to reach an outstanding number of active HTTP transactions, or GETs-in-progress.
For example, HTTP 1.1 with
Persistence allows you to execute multiple transactions
in a single connection.
Each transaction equates to the request and transfer
of one object, which for a website
is called a hit.
NOTE:
The Transactions specification applies to HTTP and HTTPS
transactions only. For certain protocols, such
as FTP, DNS, Streaming, POP3, and SMTP, use SimUsers or SimUsers/second. |
|
| Transactions/second or Transactions/hour |
Gradually ramps up the number of HTTP
transactions either per second or hour for the duration
of the test. Transactions/second or hour might not equal
connections/second or hour when using HTTP
1.1 with Persistence.
NOTE: Calibrating the load to generate
a specific transaction/second while maintaining
realistic traffic is a challenge. Since load is
generated as new users arrive, existing users
continue their transactions at non-uniform rates
due to Think Time and multiple level-2 URLs (embedded objects). The resulting
increase in transactions/second may not be smooth
due to traffic bursts created by each individual
user. |
|
NOTE: SimUsers
might be blocked from executing the next action in an
Actions list if a connection
for the action cannot be created or acquired. This can
occur if:
- The load controller detects that if by creating
a connection the desired load, load constraint, number
of connections per server, or maximum connection per
SimUser will be exceeded.
- The maximum number of connections per server or
maximum connection per SimUser has been reached and
Avalanche is waiting for one of the connections to
become available.
|
|
| Default Time Scale |
To set a default timing value that is used when individual
phase time scales are set to default, select the units of time
that Avalanche uses for the load generation. If you use the Default
Time Scale with all phases, you can easily shorten or lengthen
the entire load profile duration. Often, tests are validated using
a seconds time scale, but when a stress test is desired, a minutes
or hours time scale is preferred.
TIP: Click Set
All to Default to reset the fields to the default
values. |
|
| Total Duration |
Total amount of time that the test runs. This time is determined
by the sum of the phases defined in the Desired Load pane. |
|
Phase Editor Fields: |
| Label |
Enter a name to identify the phase you are defining. |
| Pattern |
Select a pattern from
the Pattern drop-down menu to determine the pattern in
which the load is generated for the test. For example, a flat
pattern holds the amount of load, while a stair pattern controls
the workload as it climbs or descends through a series of steps. |
| Time Scale |
Select the units of time for the selected phase's load generation.
If you want to experiment with a test of short duration, select
Default which uses the value you selected from the Default
Time Scale drop-down menu. After you perfect the test, change
the time scale to a different unit of time and scale the duration
of your test. |
| Repetitions |
If you are using a stair, burst, sinusoid, or random pattern,
enter the number of times that you want the pattern to repeat.
While it is possible to set up to 100 repetitions, the system
performs best if you limit your values between 1 and 10. Values
above 50 may cause the Load Configuration page to redraw slowly.
The actual load generation while running the test will not be
adversely affected. |
| Height |
Enter the total amount of load related to the load specification
type (for example, Connections) that Avalanche achieves. To keep
Avalanche from overwhelming your network, start small and increase
these parameters proportionately. There is no minimum height requirement,
but the upper limit must not exceed 100,000,000. |
| Ramp Time |
Enter the amount of time each step takes to reach the load
type (SimUsers, connections, and so on) applied to height. After
the load level is reached, Step Steady Time begins. For example,
if the ramp up time is 20 seconds, and the load (height) is 30,
Avalanche adds load so 30 units of load occur by the end of 20
seconds.
If you increase the number of connections to 100, you should
also increase the ramp time to 80 seconds. When using a Sinusoid
pattern, use the period to describe the period of the sinusoid;
the amount of time (or frequency) the waveform takes to complete
one cycle. There is no minimum ramp time limitation, but the upper
limit must not exceed 40,000,000.
If you are using a Sinusoid pattern, setting the ramp time to
1 results in a smoother waveform. The Ramp phase is especially
useful if you already know the relative performance threshold
of a system. For example, to test a firewall,
you can design a test that ramps up quickly to 2500 connections
a second ( conns/
sec), then steps 50 conns/ sec for 10 seconds to pinpoint the threshold. |
| Steady Time |
Enter the amount of time the step takes. Larger Step Heights
should have equally increased Step Steady Times. If the step time
is longer than it takes for the load to reach the unit count related
to the load specification type, Avalanche decreases load generation
to keep the outstanding load at a steady state equal to that of
the desired session count. There is no minimum limitation, but
the upper limit must not exceed 40,000,000. If you use a Sinusoid
pattern, set the Steady Time to 1 to achieve a smooth or waveform. |
| Period |
For Sinusoid pattern only. Enter the amount of time Avalanche
takes to gradually achieve the total load designated in the Height
field. Ramp time allows self-tuning communications to balance
the load at the start of a test run. There is no minimum limitation,
but the upper limit must not exceed 1,000. |
| Duration |
Enter the total time of a selected phase. The Load Profile
uses the combined durations of all the phases to compute the total
test duration that is displayed in the Total Duration field. |
| Enable Protocol
Exclusion |
Select to exclude certain protocols from this phase. This
means that when a SimUser is created and assigned a particular
Actions list, the actions that reference
the excluded protocols will not be executed during this phase.
For example, if you exclude the HTTP
and FTP protocols, and your Actions
list contains the following two actions, DNS
is the only action executed during this phase.
DNS A 192.168.1.1 www.somewebsite.com
1 ftp://192.168.1.1/1b
WARNING: If you
exclude all protocols,
you may have SimUsers left idle with no actions to execute. |
NOTE: SimUsers
can exist across load phases. Therefore, SimUsers can
continue to execute actions with protocols that were included in a previous
phase, but excluded
in the current phase. Only new
SimUsers created in a phase will include/exclude protocols
for that phase. |
Click Edit to select
the protocols to be excluded. In the Excluded Protocols window
that appears, use the right/left arrows to move the protocols
between the Include and
Exclude lists. After you
click Ok,
the Excluded Protocols list displays your selections. |
| Buttons |
Add: Adds a phase to the end of the load.
Remove: Removes the currently selected phase(s) from
the load.
Copy: Copies the currently selected phases directly after
the selected phases, based on the number of times that you specify
in a dialog box.
NOTE: The maximum
number of phases that you can specify in a load is 200. |
TIPS:
- Green rectangular borders indicate the currently
selected phase(s).
- The number of selected phases appears at the top
right of the graph next to the Copy button.
- You can select a single phase by clicking the phase
on the graph, clicking the left
and right 
arrow buttons, or entering the phase number (such
as 1 for the first phase) in the text field between
the arrows. The total number of phases is shown after
the slash, such as 1/15.
- You can select multiple contiguous phases by clicking
phases on the graph, while holding down the Shift
key.
- Drag the mouse over a phase to view its specifications
in a tool tip.
- To move a phase, click the phase in the graph and
drag it to a new location.
|
|
| Desired
Load Fields: |
| Desired Load |
The values that you enter in the Phase Editor pane are graphically
reflected in the Desired Load pane. The Y axis indicates the specification
of the load, such as SimUsers. The X axis indicates the time scale. |
|
Load Constraints Fields: |
| Load Constraints |
Select to control performance thresholds. Constraints are
useful if you already know the performance limits of a system.
For example, if a firewall can
support up to 16,384 connections, but you want to identify its
maximum error-free connection rate for 10k files, you would use
Connections/ Sec as the load specification
and set Max Open Connections to 16384. An unchecked constraint
means there is no limit to the constraint. A zero (0) means no
load.
Load Constraint Types for User-Based Load Profiles:
| User-Based Load Types |
Description |
| Maximum SimUsers Born |
Controls the upper limit for the total number of SimUsers
created during a test. |
| Maximum SimUsers Birth Rate |
Controls the upper limit for the number of SimUsers
created in any second throughout the test. |
| Maximum Living SimUsers |
Controls the upper limit for the number of concurrently
running SimUsers. |
Load Constraint Types for Global Load Profiles:
| Global Load Types |
Description |
| Maximum Incoming Bandwidth (bytes/
sec) |
Controls the upper limit for the incoming bandwidth
that occurs throughout the test. If the maximum is exceeded,
no more SimUsers are generated until the incoming bandwidth
falls below this value. |
| Maximum SimUsers Born |
Controls the upper limit for the total number of SimUsers
created during a test. |
| Maximum SimUsers Birth Rate |
Controls the upper limit for the number of SimUsers
created in any second throughout the test. |
|
Maximum Living SimUsers |
Controls the upper limit for the number of concurrently
running SimUsers. |
| Maximum Connection Attempts |
Controls the upper limit for the number of connection
attempts that are made throughout the test. |
| Maximum Connection Rate |
Controls the upper limit for the number of open connections
created in any second throughout the test. |
| Maximum Open Connections |
Controls the upper limit for the number of open connections. |
| Maximum Connections Error Percent |
Controls the upper limit for the percentage of connection
errors that occur during any second throughout the test. |
| Maximum Transaction Attempts |
Controls the upper limit for the number of transaction
attempts that are made throughout the test. |
| Maximum Transaction Request Rate |
Controls the upper limit for the number of transactions
that are requested at any second throughout the test. |
| Maximum Transaction Error Percent |
Controls the upper limit for the percentage of errors
that occur during any second throughout the test. |
|
| Random Seed |
Select to enable and enter a number to define the heights in
the random phases of the test. If the checkbox
is disabled or the value is 0, the seed is determined by the time
the test is executed. The last repetition of a random pattern
is always the same value as when the pattern started (the load
height ends at the same height it began). If a single repetition
is selected, the load graph on the statistics window will not
display a random value. |