Load & Performance Testing
Load testing executes a test case or suite concurrently to measure performance under varying levels of demand.
When to Use
- Establishing a baseline performance for an endpoint
- Finding the breaking point of a service under increasing load
- Verifying recovery after a sudden traffic spike
- Simulating complex, real-world traffic patterns
Creating a Load Test
- Right-click a test suite and select Add Performance Test. This creates a Load Test Case.
- Add the test steps as usual (typically a Send Request step with assertions).
- In the Properties tab, set Virtual Users and choose a load configuration.
- Run the load test case from the tree or toolbar.
Load Test Panel
The Load Test editor has three tabs:
| Tab | Purpose |
|---|
| Properties | Virtual users, error behavior, log level, description, load configuration, and the test steps grid |
| Data Generators | Configure data generators that feed varied input during the run |
| Parameters | Per-case variables (case scope) |
Properties
| Field | Description |
|---|
| Virtual Users | Number of concurrent test executions |
| Error Behavior | What happens when a user iteration fails |
| Log Level | Verbosity of the run log |
| Description | Optional notes |
| Load Configuration | A segmented selector offering Basic Load Test, Stress Test, Spike Test, Custom Load Test, and Empty Load Test |
A live chart previews the load profile (active users over time) as you configure it.
Load Test Modes
| Mode | Description | Use Case |
|---|
| Basic | Fixed number of concurrent virtual users | Establishing baseline performance |
| Stress | Gradually increasing load until failure | Finding breaking points |
| Spike | Sudden burst of traffic then normal | Testing recovery from traffic spikes |
| Custom | User-defined ramp-up, steady, and ramp-down phases | Complex real-world scenarios |
| Empty | No generated load profile (configure manually) | Advanced manual setup |
Basic Load Test
| Field | Description |
|---|
| Virtual Users | Number of concurrent test executions |
| Duration | How long to sustain the load (seconds) |
| Ramp-Up Time | Time to gradually reach full concurrency (seconds) |
Stress Test
| Field | Description |
|---|
| Start Users | Initial number of concurrent users |
| Max Users | Maximum concurrent users to reach |
| Step Size | Users to add per step |
| Step Duration | Time between steps (seconds) |
Spike Test
| Field | Description |
|---|
| Baseline Users | Normal traffic level |
| Spike Users | Peak traffic level |
| Spike Duration | How long the spike lasts (seconds) |
| Recovery Duration | How long to observe after the spike (seconds) |
During and after execution, Aethrix collects:
| Metric | Description |
|---|
| Avg Response Time | Mean request duration |
| P50 / P95 / P99 | Percentile response times |
| Time to First Byte | Average time to first byte |
| Throughput | Requests per second |
| Error Rate | Percentage of failed requests |
| Failed Iterations | Count or rate of failed iterations |
| Active Connections | Concurrent connections over time |
Load Test Assertions
Each performance metric can be used in a load test assertion with a configurable pass/fail threshold. Assertions are grouped into Service / Performance Assertions (operation-scoped) and Iteration Assertions (iteration-scoped), and produce Pass/Fail/Pending results visible in the report.
| Assertion | Scope | Metric | Threshold |
|---|
| Response Time | Operation | Avg response time | Max ms |
| Nth Percentile | Operation | Pn response time | Percentile + max ms |
| Service Pass Rate | Operation | Success rate | Min % |
| Standard Deviation | Operation | Response time std dev | Max ms |
| Time to First Byte | Operation | Avg TTFB | Max ms |
| Throughput | Operation | Requests/sec | Min req/s |
| Iteration Pass Rate | Iteration | Overall pass rate | Min % |
| Ignored Rate | Iteration | Ignored iterations | Max count or % |
| Failed Iterations | Iteration | Failed iterations | Max count or % |
See Assertions for the full load test assertion reference.
Best Practices
- Start with a Basic load test to establish baseline performance.
- Use realistic think times and data to simulate real users.
- Run load tests against a dedicated test environment — never against production.
- Monitor server-side metrics (CPU, memory, connections) alongside client-side metrics.
- Combine load tests with data-driven testing for varied request payloads.
Limitations
- Load tests run within the Aethrix process — maximum concurrency is limited by machine resources.
- For large-scale distributed load testing, consider external tools and use Aethrix for functional validation.
See Also