What is load testing and why is it done before launch?
Load testing applies simulated user traffic to an application to observe how it behaves under load measuring response times, error rates, and resource utilisation at various concurrency levels. It is done before launch because: an application that responds in 200ms for a single developer testing it may respond in 10 seconds for 500 concurrent users if the bottleneck is the database or a shared resource that degrades under concurrency. Load testing before launch identifies these breaking points while fixes are still cheap. An outage on launch day because the application could not handle the actual traffic costs the team in emergency engineering time, user trust, and revenue, and is preventable with a load test. The cost of a pre-launch load test ($4,000-25,000) is orders of magnitude less than the cost of a launch-day outage.
How much load should I test for?
Load test target selection: baseline test (the current normal daily peak the traffic level you know your application handles today, used to establish a baseline), stress test (1.5x-3x the expected peak test the capacity headroom above your expected peak traffic), spike test (the maximum instantaneous traffic you could receive typically 5-10x baseline for a product launch or viral social mention), and soak test (run baseline load for 4-24 hours continuously tests durability rather than peak capacity). The right load level depends on your actual traffic patterns: a B2B SaaS with 200 active daily users needs a different load test than a consumer app expecting 100,000 concurrent users on launch day. ClickMasters designs load tests against your actual traffic analytics not arbitrary numbers.
What is the difference between k6 and Gatling for load testing?
k6 and Gatling are both production-grade load testing tools but have different strengths. k6 (Grafana) is written in Go with a JavaScript API easy to learn for teams already writing JavaScript, lightweight (a single k6 instance can generate 10,000+ VUs on modest hardware), integrates natively with Grafana for real-time dashboards, and has a first-class cloud execution mode (k6 Cloud). k6 is the better choice for most web application load tests and CI/CD integration. Gatling (written in Scala) is designed for very high-throughput simulation a single Gatling instance can sustain 50,000+ VUs, making it appropriate for applications that need to test at very high scale. Gatling has a steeper learning curve (Scala DSL) but generates detailed HTML reports and is well-established in Java/Scala enterprise environments. ClickMasters uses k6 as the default for most B2B load testing and Gatling when the load volume requires it.
How do you know where the bottleneck is during a load test?
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.
