LOAD: Load Generator - Test Plan

Preparation

Host platform

The tests described here for the LOAD appliance are designed to run on an AppLogic grid.

3rd-party tools

None.

Tests Summary

Load Tests

• load direct - verify load is accurately generated on an appliance directly connected to the out terminal
• load in-direct - verify load is accurately generated on an application through a NET gateway connected to the out terminal
• load maximum - verify at maximum resources 1000 requests per second can be generated
• load minimum - verify at minimum resources a useful number of requests can be generated
• counter test - verify custom counters are accurately reported through the mon terminal

GUI Tests

• authentication test - verify the GUI functions properly with both an empty username and an explicitly set username and password
• graph test - verify the GUI graph against that provided by MON
• browser test - verify GUI functions in IE6x, IE7x and FireFox 2x
• URL test - verify changes to the target URL list in the GUI change the URL's actually requested

Failure Tests

• overload test - verify LOAD functions properly when more load is generated than can be served
• load_daemon failure - verify load_daemon is automatically restarted on failure (the daemon performs load generation)
• longevity test - verify LOAD functions without failure over 24 hours

Running the Tests

Copy and uncompress the test application archive file load-tst-app.tar.bz2. Import the test application.

This is a diagram of the test harness application:

Design

Structure

The test application comprises the following:

• an input gateway in configured to forward tcp traffic on ports 80, 8080 and 8081
• a port switch ps configured to forward incoming traffic on port 8080 to out1 and on port 8081 to out2
• a load generator load1 with minimum resources
• a load generator load2 with maximum resources
• a net gateway net providing internet access
• a webserver srv which serves test files
• a monitor mon

Test Details

There are two resources on the web server in the application which are used for the tests:

• tiny - a 69 Byte file.
• large - a 59.9 Kb file.

Appliance load1 uses minimum resources and is connected to the net gateway. Its targets can be entered as:

• http://1.2.3.4/tiny
• http://1.2.3.4/large

Appliance load2 uses 1 CPU and minimum memory resources and is connected directly to the in terminal of the web server. Its targets can be entered as:

• http://out/tiny
• http://out/large

Load Tests

• load direct - verify load is accurately generated on an appliance directly connected to the out terminal
  • Point a browser at port 8081 of the application in_ip
  • Using large, generate load at different rates and verify that the reported results are sane:
    • fetches/second should closely match requests/second while all response codes are 200
    • bytes/connection should be 59.9 Kb.
  • Note: at some point the web server will be unable to serve all of the requests and requests per second will no longer match fetches per second.
• load in-direct - verify load is accurately generated on an application through a NET gateway connected to the out terminal
  • Point a browser at port 8080 of the application in_ip
  • Using large, generate load at different rates and verify that the reported results are sane:
    • fetches/second should closely match requests/second while all response codes are 200
    • bytes/connection should be 59.9 Kb.
  • Note: at some point the web server will be unable to serve all of the requests and requests per second will no longer match fetches per second.
• load maximum - verify with 1.0 CPU, 2000 requests per second can be generated
  • Point a browser at port 8081 of the application in_ip
  • Using tiny, select a rate of 2000. Verify fetches/second closely matches 2000.
• load minimum - verify at minimum resources a useful number of requests can be generated
  • Point a browser at port 8080 of the application in_ip
  • Using tiny, select a rate of 100. Verify fetches/second closely matches 100.
• counter test - verify custom counters are accurately reported through the mon terminal
  • Point a browser at port 8081 of the application in_ip
  • Select a rate of 100.
  • Open the monitoring view of the application. Add a graph including these custom counters for Load:
    • Bytes per connection
    • Bytes per second
    • Fetches per second
    • Max msec per connection
    • Max msec per first response
    • Max parallel
    • Mean msec per connection
    • Mean msec per first response
    • Min msec per connection
    • Min msec per first response
    • Requests per second
  • Verify the counters closely match the values reported in the GUI. Note that counter values are rounded to integers.
  • Select a rate of 0. Verify all counter values are 0.

GUI Tests

• authentication test - verify the GUI functions properly with both an empty username and an explicitly set username and password
  • Select one of the LOAD appliances.
  • Set username and password explicitly. Either set these properties and re-start the application, or simply edit /etc/applogic.sh. Point a browser at the GUI and verify authentication is performed.
  • Set username and password to empty. Point a browser at the GUI and verify authentication is not performed.
  • Set username explicitly and password to empty. Point a browser at the GUI and verify the empty password is used for authentication.
• graph test - verify the GUI graph against that provided by MON
  • Examine side by side a LOAD GUI and MON graphs for its Load counters
  • Generate a variety of load changes. Verify the graphs are nearly in sync.
• browser test - verify GUI functions in IE6x, IE7x and FireFox 2x
  • Open the LOAD GUI in each of IE6x, IE7x and FireFox 2x. Verify the rendering is acceptably uniform. Verify the GUI functions properly in each browser.
• URL test - verify changes to the target URL list in the GUI change the URL's actually requested
  • Point a browser at port 8081 of the application in_ip
  • Change the target URL list to use large and select a load of 50
  • Verify that bytes/connection is 59.9 Kb.
  • Change the target URL list to include both tiny and large
  • Verify that bytes/connection is near an average of 30 Kb.
  • Change the target URL list to include exactly http://out/not_here
  • Verify that bytes/connection is about 206

Failure Tests

• overload test - verify LOAD functions properly when more load is generated than can be served
  • Point a browser at port 8081 of the application in_ip
  • Change the target URL list to use large and select a load of 2000
  • Verify that fetches/second is less than 2000. HTTP response codes other than 200 may be returned.
  • After one minute change the rate to 100. Shortly, fetches/second should again closely match the rate.
• load_daemon failure - verify load_daemon is automatically restarted on failure (the daemon performs load generation)
  • Open a shell to main.load.load1
  • Execute /usr/LOAD/stopd
  • Verify that load_daemon is restarted within two minutes using ps aux | grep load_daemon
• longevity test - verify LOAD functions without failure over 24 hours
  • Using large, select a load near the maximum which can be served. Close the browser. After 24 hours, point a browser at LOAD again. Verify it is still generating the selected load.

-- StephenQ - 08 Jan 2008