26 September 2007 - 1.7.6 | home user-guide eclipse jbossws intellij netbeans maven 1.X/2.X PDF files forums bugs sourceforge

Home
Getting Started
User Guide

- Overview
  - Tabbed Desktop
  - License Management
  - Preferences
  - XPath Selection
  - Script Library
- Workspaces
- Projects
- Interfaces
  - Interface Viewer
- Operations
- Working with Requests
  - Form Editor
  - Overview View
  - Outline Editor
  - Message Inspectors
  - Attachments/Inline Files
- Functional Testing
  - Getting Started
  - TestSuites
  - TestCases
    - Test Requests
      - Assertions
      - Editor Wizards
    - Property Transfers
    - Conditional Gotos
    - Groovy Scripts
      - Examples
      - GroovyUtils
    - Properties Step
    - Delay Step
    - Mock Response
    - DataSource
    - DataSource Loop
  - Property Expansion
- Load Testing
  - Getting Started
  - Limit & Strategies
  - Execution
  - Assertions
  - Diagrams
  - JMeter comparison
- Mocking
  - Getting Started
  - Mock Services
  - Mock Operations
  - Mock Responses
- Usage Scenarios
  - Data-Driven Testing
  - Template-Driven Testing
  - Interactive Testing
  - Surveillance Testing
- Tool Integrations
  - Code Generation
  - WSDL Generation
  - WS-I Tools
  - Apache Tcp-Mon
- CommandLine Tools
  - TestCaseRunner
  - LoadTestRunner
  - MockServiceRunner
  - ToolRunner
- Keyboard shortcuts

IDE/Tool Plugins
Search soapUI site
Project Documentation

- About soapUI
- Project Info
- Project Reports

## LoadTest Configuration

The actual execution of a LoadTest is configured in two dimensions:

- The LoadTest Limit controls how long a LoadTest should run
- The LoadTest Strategies control how TestCases are scheduled and threaded (ie run in parallel)

### LoadTest Limit

The LoadTest Limit is specified on the top right of the LoadTest Editor and consists of two settings:

- Limit : specifies for how many TestCase runs or seconds the LoadTest should run
- Limit Type : specifies how to limit the LoadTest; Seconds will run the LoadTest for the specified time, Total Runs will run the underlying TestCase for the specified number of times in total.

Please note that the "Total Runs" Limit Type does not mean per thread but in total; if for example setting the Limit to 1000 and configuring 5 threads, each thread will run approximately 200 requests (depending on exection times..).

Setting the Limit to 0 with either Limit Types will run the LoadTest indefinitely. A progress-bar to the right of the settings will show the current LoadTest progress.

### LoadTest Strategies

A LoadTest can in soapUI be run using a number of strategies for how TestCases are executed. All strategies have a thread-count allowing the specification of how many TestCases that should be run in parallel. The current strategy is selected using the available Strategy combo, which will show that strategies settings to its right. Some strategies allow interactive changing of the thread-count while executing the LoadTest, others don't.

The following LoadTest Strategies are currently available:

- Simple : TestCase execution with a configurable delay
- Variance : TestCase execution varying the number of threads over time
- Burst : TestCase execution in "bursts"
- Thread : TestCase execution with a fixed thread-count modification

Since multiple LoadTests with different strategies can be created one could for example create one LoadTest with a simple "base" load using the Simple strategy and another LoadTest using the Burst strategy to monitor how base performance is affected when running both LoadTests simultaneously within soapUI or from the command-line.

### Simple

The Simple Strategy has the following settings:

- Test Delay : sets a delay between each TestCase run
- Random : sets how much of the delay to randomize

Use this for simple load testing. For example setting the delay/random to 1000/0.5 will delay each threads TestCase execution by 500 to 1000 ms. Setting the delay to 0 will ignore the random setting and run without any delays.

If setting a delay be aware that the TPS statistic will give misleading results unless the "Calculate TPS on actual time passed" option is selected in the LoadTest Options dialog

### Variance

The variance strategy has the following settings:

- Interval : sets the duration of each variance cycle in seconds
- Variance : sets how much the thread-count should be varied during the cycle

Use this strategy for simulating a linearly varying number of threads over time. The strategy will start at the currently configured thread-count, increase to current + (current*variance), decrease to current - (current*variance) and increase back to the current thread-count.

For example setting the thread-count to 20, duration to 480 and variance to 0.5, the strategy will increase from 20 to 30 threads in the first 2 minutes, decrease to 10 threads of the next 4 minutes and then increase back to the original 20 in the last 2 minutes.

### Burst

The Burst strategy has the following settings:

- Burst Delay : sets the delay between each burst
- Burst Duration : sets duration for each burst

Use this strategy to simulate a "burst" load and for example monitor system behaviour during the "recovery" periods

For example setting the limit-type to seconds and limit to 600, the thread-count to 30, burst delay to 50 and burst duration to 10 will pause all 30 threads for 50 seconds and run them for 10 seconds repeatedly under 10 minutes.

### Thread

The Threads Strategy has the following settings:

- Start Threads : sets the number of threads to start at
- End Threads : sets the number of threads to end at

Use this strategy to vary the number of threads from a start to end value linearly during the entire LoadTest. This can for example be useful to find the thread-count at which the best TPS is achieved.

For example setting the limit-type to seconds and limit to 600, the start threads to 1 and end threads to 30 will increase the number of threads from 1 to 30 over 10 minutes.

Next: LoadTest Execution