Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
85 changes: 85 additions & 0 deletions load_testing/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,85 @@
# School Profiles - Load Testing

Comprehensive and scalable load testing suite for School Profiles services using [k6](https://grafana.com/products/k6/).
This was "borrowed" from https://github.com/DFE-Digital/publish-teacher-training/tree/main/load_testing

## Setup

1. **Install k6:**

*macOS*
```
brew install k6
```

*Linux (Debian/Ubuntu)*

```
sudo apt install k6
```

## Services

#### Local/Development Runs

**Super quick local test (5 users, 10s):**
```
k6 run -e SESSION_ID=<gatewaycookieid> load-test.js
```

**Baseline, peak, and stress local:**
```

k6 run -e SESSION_ID=<gatewaycookieid> --env SCENARIO=baseline load-test.js
k6 run -e SESSION_ID=<gatewaycookieid> --env SCENARIO=peak-surge load-test.js
k6 run -e SESSION_ID=<gatewaycookieid> --env SCENARIO=stress load-test.js
k6 run -e SESSION_ID=<gatewaycookieid> --env SCENARIO=quick load-test.js
```

## Test Scenarios - TBC

### Baseline Test
- **Users**: 200 concurrent
- **Duration**: 14 minutes
- **Purpose**: Normal operations validation

### Peak Surge Test
- **Users**: 3000 concurrent at peak
- **Duration**: 15 minutes
- **Purpose**: "load opens" event (45k requests in 5 minutes)
- **Target RPS**: 150 sustained

### Stress Test
- **Users**: 4000+ concurrent
- **Duration**: 25 minutes
- **Purpose**: Breaking point identification
- **Target RPS**: 200+ sustained

***

## User Journey Mix

- User visits home page (All tests)
- User visits all KS2 profile pages (15%)
- User visits all KS4 profile pages (15%)
- User visits all KS5 profile pages (15%)
- User searches for "school", pages through 5 page, then filters on postcode, and clicks through to the about page (25%)
- User has 5 schools in their MySchools list and clicks every page to view their comparison (30%)

***

## Key Metrics - TBC

- **Response Time**: <3s for 95% of requests
- **Error Rate**: <1% during normal load
- **Throughput**: 150 RPS during peaks
- **Availability**: 99.9% uptime target

***

## Output & Monitoring

- **Local:**
Results printed in terminal; JSON (`*-summary.json`) can be exported for deeper analysis.
- **Cloud (Grafana):**
Real-time dashboards, historic tracking, and alerting available in Grafana Cloud (requires authentication).
45 changes: 45 additions & 0 deletions load_testing/ToDo.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
# User Journey Confirmation

We need to confirm the user journeys that have been defined, including:

- The percentage of users expected to follow each journey path.
- The currently defined journeys for:
- Load homepage
- KS2
- KS4
- KS5
- The three search journey types, including postcode and multi-page searching
- The "Compare or My Schools" journey

# Capacity and Load Assumptions

We have assumed that the service limits will be pushed towards their upper threshold. In other words:

- We are not targeting a specific number of users.
- Instead, we are validating that the platform can support a defined maximum number of users.
- If this level of capacity does not meet product requirements, the assumptions and test approach will need to be reviewed.

We also need confirmation on the scope of testing:

- Are all pages considered equally important and therefore required to be tested?
- Or should testing focus on a prioritised subset of pages?

# Performance Targets

Current assumptions are:

- Homepage load time: **2 seconds**
- Search results load time: **3 seconds**

However, these targets can be adjusted on a per-journey basis. Product input is required to confirm whether these performance thresholds are appropriate for each user journey.

# Product Decisions Required

From a technical perspective, the core requirements have been met. However, several product decisions are still required to provide a complete and meaningful view of performance, including:

- Confirmation of user journeys and traffic distribution.
- Agreement on testing scope and page prioritisation.
- Validation of journey-specific performance targets.
- Confirmation that the proposed capacity assumptions align with business expectations.

These decisions will enable us to establish a more accurate and comprehensive performance assessment.
Loading
Loading