Execution Modes
Overview
When executing a test configuration (a set of tests against an endpoint), Rhesis supports two execution modes: Sequential and Parallel. The mode determines how multiple tests are scheduled and executed.
Parallel Execution (Default)
Description
Tests are executed simultaneously using multiple Celery workers. This is the default mode and provides the fastest execution time.
How It Works
- Tests are dispatched to available workers
- Multiple tests run concurrently
- Results collected when all complete
- Uses Celery’s chord primitive for coordination
Use Cases
✅ Best for:
- Endpoints that can handle concurrent requests
- Independent tests (no dependencies)
- Fast execution needed
- Scalable endpoints without rate limits
- High-performance testing scenarios
- Large test suites
⚠️ Considerations:
- May overwhelm endpoints
- Harder to debug concurrent failures
- Requires adequate system resources
- May hit rate limits
Configuration
Parallel is the default mode. No configuration needed:
Or explicitly set:
Sequential Execution
Description
Tests are executed one after another in sequence. Each test must complete before the next one starts.
How It Works
- Tests execute in order
- One test at a time
- No concurrent load on endpoint
- Predictable execution pattern
Use Cases
✅ Best for:
- Endpoints with rate limiting
- Endpoints that can’t handle concurrent load
- Tests with dependencies on each other
- Debugging test execution issues
- Limited endpoint resources
- Stateful testing scenarios
⚠️ Considerations:
- Slower overall execution time
- Less efficient resource utilization
- Longer wait times for results
Configuration
Set in test configuration attributes:
Or programmatically:
Implementation Details
Execution Flow
Both modes produce identical result structures:
Result Processing
Both modes use the same collect_results task for consistency:
- Status tracking:
status,final_status,task_state - Progress metrics:
completed_tests,failed_tests,total_tests - Timing information:
started_at,completed_at,execution_time - Email notifications triggered for both modes
Task Orchestration
Parallel Mode (parallel.py)
Uses Celery’s chord primitive:
Sequential Mode (sequential.py)
Uses Celery’s chain primitive:
Choosing an Execution Mode
Decision Matrix
| Scenario | Recommended Mode | Reason |
|---|---|---|
| Production regression suite | Parallel | Fast feedback, independent tests |
| Rate-limited API | Sequential | Avoid hitting rate limits |
| Development/debugging | Sequential | Easier to trace issues |
| High-traffic endpoint | Parallel | Endpoint designed for load |
| Tests have dependencies | Sequential | Ensure proper order |
| Small test suite (< 5 tests) | Either | Minimal time difference |
| Large test suite (> 50 tests) | Parallel | Significant time savings |
| Stateful endpoint | Sequential | Maintain state consistency |
Performance Comparison
Example with 20 tests, 5s average test time:
| Mode | Execution Time | Resource Usage |
|---|---|---|
| Parallel (5 workers) | ~20-25 seconds | High |
| Sequential | ~100 seconds | Low |
Utilities
Get Current Mode
Get Mode Description
Get Recommendations
Monitoring and Debugging
Parallel Mode
Sequential Mode
Common Issues
Parallel Mode:
- Endpoint returns 429 (rate limit) → Switch to Sequential
- Inconsistent test results → Check for race conditions
- Worker overload → Reduce concurrency or use Sequential
Sequential Mode:
- Tests taking too long → Consider Parallel if endpoint can handle it
- Bottleneck in single test → Optimize that test first
Related Documentation
- Test Execution System - Overall architecture
- Test Types - Single-turn vs Multi-turn
- Background Tasks - Celery configuration
- Architecture - Worker system details