Performance Test Plan — Product Name v0.0

Document ID: PTP-XXX Author: Name Date: YYYY-MM-DD Status: Draft / Review / Approved

---

1. Introduction

1.1 Purpose

State which release, feature set, or system this plan covers, and what performance risk it addresses.

1.2 Scope

In scope:

• Journey or endpoint 1
• Journey or endpoint 2

Out of scope:

• Excluded area — reason

1.3 References

• PRD / SLA document link
• Related test plan (if applicable)
• Previous performance baseline report (if applicable)

---

2. Performance Objectives (NFRs)

NFR	Target	Measurement	Rationale
Response time (p95)	< X ms	p95 from tool output	User experience threshold
Throughput	≥ X RPS	Requests/second sustained	Peak traffic estimate
Error rate	< X %	HTTP 5xx / total requests	Availability SLA
Concurrent users supported	X	Virtual users without degradation	Modelled from analytics

Add or remove rows to match the system under test.

---

3. Test Types

Type	Description	Goal
Load test	Sustained expected load over a defined period	Confirm NFRs are met under normal conditions
Stress test	Load ramped beyond expected peak to find the breaking point	Identify where the system degrades and fails
Spike test	Sudden, sharp increase in load followed by a return to baseline	Confirm recovery and absence of memory/connection leaks
Soak / endurance test	Sustained load over an extended period (hours)	Detect slow memory leaks, connection pool exhaustion, and degrading response times

---

4. Test Environment

4.1 Hardware / Infrastructure

Describe server specs, container sizes, database instance types, and CDN / cache configuration.

4.2 Network Conditions

Describe latency simulation, geographic distribution of load generators (if any), and whether a VPN or dedicated network is used.

4.3 Test Data Volume

Describe the data set size in the test environment and how it compares to production.

4.4 Differences from Production

Difference	Why it exists	Risk it introduces
e.g. Smaller DB instance	Cost	Results may understate real performance

---

5. Tools and Instrumentation

Category	Tool	Purpose
Load generator	k6 / JMeter / Gatling / Locust	Generate virtual user traffic
APM	Datadog / New Relic / Grafana	Server-side metrics during the run
Result storage	InfluxDB / k6 Cloud / CSV	Persist run data for comparison
Profiling	Optional — e.g. async-profiler	Identify hotspots if a bottleneck is found

---

6. Test Scenarios

Scenario	User journey	Load profile	Duration	Pass criteria
Baseline load	Journey description	X VUs, constant	10 min	NFRs met
Stress ramp	Journey description	X → Y VUs, step-up every 2 min	20 min	No crash; graceful degradation
Spike	Journey description	X VUs → 3× spike for 60 s	5 min	Recovery within 2 min
Soak	Journey description	X VUs, constant	2 h	p95 < threshold throughout

---

7. Entry and Exit Criteria

7.1 Entry Criteria

• Load test environment provisioned and confirmed accessible
• Smoke test against the environment passes
• Test data seeded and verified
• Monitoring dashboards confirmed active
• Baseline from previous run available (if applicable)

7.2 Exit Criteria

• All scenarios executed
• NFR pass/fail verdict recorded for each NFR
• All critical and high bottlenecks triaged
• Performance test report published

---

8. Risks and Mitigations

Risk	Likelihood	Impact	Mitigation
Environment instability	Medium	High	Run smoke test before full suite; re-run if environment restarted
Test data not representative	Low	Medium	Validate data volume against production before run
Third-party dependency rate-limiting	Medium	Medium	Stub or exclude third-party calls; document assumption

---

9. Schedule and Roles

Task	Owner	Target Date
Environment setup	Name	Date
Script development and review	Name	Date
Load test execution	Name	Date
Stress and spike test execution	Name	Date
Soak test execution	Name	Date
Report published	Name	Date

---

10. Deliverables

• Completed test scripts (committed to repository)
• Run data exported and stored in location
• Performance test report

Performance Test Plan — AcmeCorp Checkout API v2.4

Document ID: PTP-2024-011 Author: Jordan Osei Date: 2024-04-08 Status: Approved

---

1. Introduction

1.1 Purpose

This plan covers load, stress, spike, and soak testing for the AcmeCorp Checkout API v2.4, which introduces a rewritten payment orchestration layer ahead of the summer sale period. The primary concern is that the new orchestration layer introduces additional async processing that may degrade response times under peak load.

1.2 Scope

In scope:

• Checkout initiation (POST /api/v2/checkout)
• Payment confirmation webhook processing (POST /api/v2/payments/confirm)
• Order status polling (GET /api/v2/orders/{id}/status)

Out of scope:

• Catalogue browse and search APIs (covered by a separate plan)
• Third-party payment provider certification (provider's responsibility)
• Frontend load testing (static assets served via CDN)

1.3 References

• PRD: Confluence/ACME-PRD-CHECKOUT-2.4
• SLA document: SLA-ECOMM-2024 (99.9% availability, p95 < 800 ms under peak)
• Previous baseline: PTP-2024-007 (v2.3 results)

---

2. Performance Objectives (NFRs)

NFR	Target	Measurement	Rationale
Response time (p95) — checkout initiation	< 800 ms	p95 from k6 output	SLA commitment
Response time (p95) — order status poll	< 300 ms	p95 from k6 output	Polling interval is 1 s; must not stack
Throughput	≥ 500 RPS sustained	Requests/second over 10-min window	Summer sale peak estimate (+40% on last year)
Error rate	< 0.1%	HTTP 5xx / total requests	Availability SLA
Concurrent users	1 000	Virtual users without p95 degradation	Analytics model: 2× expected peak

---

3. Test Types

Type	Description	Goal
Load test	500 RPS sustained for 15 min	Confirm NFRs are met under normal peak conditions
Stress test	Ramp from 500 RPS to 1 500 RPS in 5 × 200 RPS steps	Find the breaking point of the orchestration layer
Spike test	500 RPS → 1 000 RPS for 60 s → back to 500 RPS	Validate autoscale response and recovery
Soak test	500 RPS for 3 h	Detect connection pool exhaustion under the new async layer

---

4. Test Environment

4.1 Hardware / Infrastructure

• API: 3 × t3.large containers (ECS Fargate), matching the production task definition
• Database: RDS PostgreSQL db.r6g.large (production uses db.r6g.2xlarge — see differences table)
• Cache: ElastiCache Redis r6g.large — matches production

4.2 Network Conditions

• Load generators run from AWS eu-west-1, same region as the test environment
• No latency simulation — direct VPC peering between generators and API
• Third-party payment provider is stubbed via WireMock (avoids rate-limiting)

4.3 Test Data Volume

• 50 000 customer accounts seeded (production: ~2 M)
• 200 000 product SKUs seeded (production: ~180 000 — effectively comparable)
• Payment method tokens pre-seeded to avoid tokenisation latency in results

4.4 Differences from Production

Difference	Why it exists	Risk it introduces
Smaller DB instance (r6g.large vs r6g.2xlarge)	Cost	DB may become the bottleneck before the orchestration layer does — results may understate real peak headroom
Stubbed payment provider	Avoid rate limiting	Removes real network latency from the provider leg (~120 ms in production)
Fewer autoscale nodes (3 vs 6 max)	Cost	Stress test may exhaust capacity sooner than in production

---

5. Tools and Instrumentation

Category	Tool	Purpose
Load generator	k6 v0.50	Generate virtual user traffic; output to InfluxDB
APM	Datadog	Server-side CPU, memory, DB connections, p99 per endpoint
Result storage	InfluxDB + Grafana dashboard	Persist and visualise run data in real time
Profiling	async-profiler (on standby)	Flame graphs if CPU hotspot found during stress ramp

---

6. Test Scenarios

Scenario	User journey	Load profile	Duration	Pass criteria
Baseline load	Checkout initiation + order status poll	500 RPS, constant	15 min	All NFRs met
Stress ramp	Checkout initiation	500 → 1 500 RPS, +200 RPS every 2 min	12 min	Identify breaking point; no data corruption
Spike	Checkout initiation	500 → 1 000 RPS for 60 s → 500 RPS	5 min	p95 recovers to < 800 ms within 2 min of spike end
Soak	Checkout initiation + confirmation webhook	500 RPS, constant	3 h	p95 stays < 800 ms throughout; error rate < 0.1%

---

7. Entry and Exit Criteria

7.1 Entry Criteria

• Test environment provisioned and confirmed accessible
• Smoke test (10 RPS for 60 s) passes with 0 errors
• Test data seeded and spot-checked (5 orders placed manually)
• Datadog dashboard confirmed streaming data
• k6 scripts peer-reviewed and merged to the perf-tests branch

7.2 Exit Criteria

• All four scenarios executed
• NFR pass/fail verdict documented for each NFR
• All Critical and High bottlenecks triaged with dev lead
• Performance test report published within 48 h of final run

---

8. Risks and Mitigations

Risk	Likelihood	Impact	Mitigation
Test DB becomes bottleneck before API layer	High	High	Monitor DB CPU/connections separately; document if DB saturates first
k6 generator itself becomes a bottleneck	Low	Medium	Distribute load across 3 generators; validate generator CPU < 60% at peak
Summer sale date moves earlier	Low	High	Execute soak test first so at least endurance data is in hand
WireMock stub diverges from real provider behaviour	Medium	Medium	Validate stub response times against a real provider sample weekly

---

9. Schedule and Roles

Task	Owner	Target Date
Environment setup and smoke test	DevOps — Sam Reid	2024-04-10
k6 script development and review	Jordan Osei	2024-04-12
Baseline load test execution	Jordan Osei	2024-04-15
Stress and spike test execution	Jordan Osei	2024-04-16
Soak test execution (3 h window, overnight)	Jordan Osei	2024-04-17
Report published	Jordan Osei	2024-04-19

---

10. Deliverables

• k6 scripts committed to github.com/acmecorp/perf-tests/checkout-v2.4
• Run data exported to InfluxDB bucket checkout-v24-perf
• Performance test report (PTP-REPORT-2024-011)