Load Testing Services

• Baseline Test: Simulates normal expected load the traffic the application handles day-to-day. Key question: what is the P95 response time at normal load? When to run: before every major release establish the baseline.
• Stress Test: Load gradually increased beyond normal until performance degrades or errors appear. Key question: at what concurrent user count does the application break? When to run: before a major launch know the capacity limit.
• Spike Test: Sudden sharp increase in load (2x-10x normal) followed by return to normal. Key question: does the application survive a sudden traffic spike? Does it recover? When to run: before a marketing campaign or product launch that will drive a traffic spike.
• Soak Test: Sustained normal load over an extended period (4-24 hours). Key question: are there memory leaks, connection pool exhaustion, or gradual degradation over time? When to run: before production especially for applications that have not been run continuously under load.
• Scalability Test: Load increased incrementally verify that adding capacity (more containers, larger DB) improves performance proportionally. Key question: does horizontal scaling actually help? Is the bottleneck in the application or the database? When to run: when planning infrastructure scaling or auto-scaling configuration.
• Breakpoint Test: Load increased until the application fails completely measure the failure point. Key question: what is the absolute maximum capacity before complete failure? When to run: before capacity planning decisions understand the hard ceiling.

Bottleneck identification during a load test uses correlated monitoring across all application layers simultaneously. Infrastructure layer: CloudWatch metrics for ECS CPU utilisation, RDS CPU and connections, ElastiCache memory, ALB 5xx rate watch which metric saturates first as load increases. Application layer: Node.js inspector or clinic.js heap profiling under load is CPU saturating in the application (event loop blocking) or are most threads waiting for I/O? Database layer: pg_stat_statements query durations during the load test do query times increase with load (indicates lock contention or resource exhaustion) or stay constant (indicates the query is efficient at any load)? Connection pool: PgBouncer stats (pool wait time, queue length) if applications are waiting for a database connection, PgBouncer pool size is the bottleneck. The bottleneck is almost always the first resource that saturates increasing load beyond that point degrades everything downstream. ClickMasters instruments all layers before running a load test to ensure bottleneck identification is immediate.

Auto-scaling validation ensures your infrastructure can handle traffic spikes without manual intervention. The key metrics: trigger threshold (what CloudWatch alarm triggers the scale-out? at what CPU or request count?), scale-out timing (how long from trigger to new instances receiving traffic? If auto-scaling takes 3 minutes but the spike lasts 2 minutes, it doesn't help), scale-under-load (are new instances healthy and processing traffic before existing instances are overwhelmed?), database response under scale-out (does adding application instances cause database connection exhaustion? if yes, no amount of application scaling helps), scale-in validation (after load decreases, do instances scale in correctly? no stuck instances, no premature scale-in causing second degradation). ClickMasters validates auto-scaling configuration as part of the load test including measuring the scale-out timing and validating that the database layer can handle the increased connection demand.