Skip to content

Performance Test Plan Care Leavers Website

Performance Test Plan: Care Leavers Website


1. Objective

To validate that the Care Leavers website can handle expected and peak user loads without performance degradation, while ensuring Azure infrastructure remains cost-effective.


2. Assumptions

  • No historical traffic data is available.
  • Based on comparable GovUK services, estimated traffic is 1,000 users/month.
  • Peak usage is expected during UK business hours.

Projected Usage:

  • Normal: 30 concurrent users (~3 requests/sec)
  • Spike: 90 concurrent users (~9 requests/sec)
  • Stress: 150 concurrent users (~15 requests/sec)

3. User Journeys (Thread Groups)

The test will simulate 7 primary user journeys across the site: 1. Home -> Money & Benifits -> LeavingCareAllowance 2. Home -> All Support -> Housing & Accomadation ->Leaving care Allowance 3. Home -> YourRights -> FormerRelaventChild 4. Home -> Guides -> WhatHappens when you leave care 5. Home -> Helplines 6. USAC page directlly 7. Pathway Plan -> Translate -> Arabic

Each journey will be represented by a separate Thread Group.


4. Test Scenarios

Scenario 1: Baseline Test

  • Users: 1 per thread group (7 total threads)
  • Ramp-up: 7 seconds
  • Loop Count: 1
  • Goal: Validate basic functional behavior and response times (< 3 seconds)

Scenario 2: Normal Load

  • Users: 30 users total (distributed across thread groups)
  • Ramp-up: 60 seconds
  • Loop Count: Based on 5-minute session duration
  • Throughput Goal: ~3 RPS

Scenario 3: Spike Load

  • Users: 90 users total
  • Ramp-up: 90 seconds
  • Duration: 10 minutes
  • Throughput Goal: ~9 RPS

Scenario 4: Stress Test

  • Users: 150 users total
  • Ramp-up: 120 seconds
  • Duration: 10–15 minutes
  • Goal: Observe system limits, monitor infrastructure metrics

5. Configuration Details

  • HTTP Cookie Manager: Added to each Thread Group with "Clear cookies each iteration" enabled.
  • HTTP Cache Manager: Added with "Clear cache each iteration" enabled.
  • Timers: Constant or Gaussian timers to simulate real user think time.
  • Assertions: Response time assertions (< 3000ms), HTTP status = 200
  • Listeners: Aggregate Report, Summary Report, Response Time Graph

6. Success Criteria

  • < 1% error rate
  • Average response time < 2 seconds
  • 95th percentile < 3 seconds
  • Consistent throughput without errors
  • No major infrastructure bottlenecks (CPU, Memory, Redis Cache, Contentful API)

7. Tools & Monitoring

  • JMeter for load generation
  • Azure Monitor / Application Insights for backend monitoring
  • Contentful Metrics (if available)
  • Redis Cache Monitoring (Azure Redis Insights)

8. Risks & Mitigations

Risk Mitigation
Lack of historical data Start with conservative load assumptions
Backend API slowness Monitor third-party response times
Infrastructure limits Tune Azure scaling rules post-test

9. Next Steps

  • Prepare .jmx file with 7 thread groups
  • Configure ramp-up, user load, and loops per scenario
  • Schedule Normal, Spike, and Stress tests
  • Review metrics and performance dashboards

Prepared by: Varsha Krishnamurthy Date: 3/04/25 Project: DfE Care Leavers