2.1.2.3. Load, Stress, Performance, and Application Testing at Scale

2.1.2.3. Load, Stress, Performance, and Application Testing at Scale

Performance testing validates that your application meets non-functional requirements (latency, throughput, error rate) under realistic load. Without it, you discover scaling limits in production — during a traffic spike.

Test types and their purpose:

• Load testing: Applies expected production traffic levels to verify the system handles normal load. Validates auto-scaling thresholds are set correctly.
• Stress testing: Pushes beyond expected capacity until failure. Reveals the breaking point and how the system degrades (graceful degradation vs. crash).
• Soak testing: Runs sustained load over hours/days to detect memory leaks, connection pool exhaustion, and resource drift.
• Spike testing: Applies sudden traffic bursts to validate auto-scaling speed and ALB warm-up behavior.

AWS tools for performance testing:

• AWS Distributed Load Testing Solution (CloudFormation-based) uses Fargate containers to generate HTTP load from multiple regions. Specify requests/second, ramp-up time, and duration.
• AWS Device Farm tests mobile and web apps on real devices. Use it for E2E latency and rendering performance.
• Amazon CloudWatch RUM captures real user performance metrics (page load time, JS errors) from production browsers.

Key metrics to watch during performance tests:

• Application: p50/p95/p99 latency, error rate, throughput (requests/sec)
• Infrastructure: CPU utilization, memory, network I/O, disk queue depth
• Scaling: ASG DesiredCapacity, target tracking alarm state, ALB active connection count

Exam Trap: If a question describes "the application performs well under load testing but experiences latency spikes in production," the likely cause is either cold start delays (Lambda), insufficient ALB warm-up (pre-warming required for sudden traffic), or cross-AZ data transfer latency not present in single-AZ test environments.