What is the difference between load testing, stress testing, and spike testing?

Load testing: measure performance under expected user volume (e.g., 1000 concurrent users). Stress testing: push beyond expected limits to find the breaking point (e.g., ramp to 10,000 users until errors appear). Spike testing: sudden burst of traffic (e.g., 0 to 5000 users in 10 seconds) to test auto-scaling and recovery. Each answers a different question: "Can we handle normal traffic?" vs. "When do we break?" vs. "Can we handle sudden surges?"

What key performance metrics should you monitor during a load test?

Response time (p50, p95, p99 — not just average), throughput (requests per second), error rate (% of failed requests), concurrent users, and resource utilization (CPU, memory, disk I/O, network). p95 and p99 are more important than average — they show worst-case user experience. Also monitor: database query times, connection pool usage, queue depth, and garbage collection pauses.

Compare JMeter, k6, and Gatling. When would you use each?

JMeter: GUI-based, Java, huge plugin ecosystem, great for complex protocols (SOAP, JMS, JDBC), but resource-heavy per thread. k6: JavaScript-based, lightweight Go runtime, modern API, excellent for CI/CD integration and developer-written tests, but fewer protocols than JMeter. Gatling: Scala-based, code-first approach, excellent reports, efficient non-blocking architecture. Choose k6 for developer teams and CI integration, JMeter for complex enterprise protocols, Gatling for high-performance Scala shops.

How do you identify performance bottlenecks from load test results?

Systematic approach: (1) Correlate response time degradation with resource metrics — does CPU spike when response times increase? (2) Check database — slow queries (enable slow query log), connection pool exhaustion, lock contention. (3) Check application — thread pool saturation, memory leaks (heap growth over time), GC pauses. (4) Check infrastructure — network bandwidth, disk I/O, load balancer distribution. (5) Use APM tools (Datadog, New Relic) to trace individual slow requests through the stack.

How do you write a k6 load test script?

Basic structure: define `options` (stages for ramp-up/down, thresholds for pass/fail), export a `default function` with HTTP requests and checks. Example: `export const options = { stages: [{ duration: "2m", target: 100 }, { duration: "5m", target: 100 }, { duration: "2m", target: 0 }], thresholds: { http_req_duration: ["p(95)<500"] } }`. Use `check()` for assertions, `group()` for logical grouping, and `sleep()` for think time between requests.

What is think time and why is it important in load testing?

Think time simulates the pause between user actions — a real user reads a page for 5-30 seconds before clicking the next link. Without think time, your load test generates unrealistically high request rates (each virtual user fires requests back-to-back), making results inaccurate. Too much think time underestimates load. Use realistic think times based on analytics data. In k6: `sleep(Math.random() * 5 + 2)` for 2-7 second random pauses.

How do you test the performance of a database-heavy application?

Beyond HTTP load testing, directly test the database layer: (1) Query performance — EXPLAIN plans for critical queries, index coverage. (2) Connection pooling — test pool exhaustion under load. (3) Read/write ratio — mirror production patterns. (4) Data volume — test with production-scale data (not a tiny dev DB). (5) Lock contention — concurrent updates to the same rows. (6) Replication lag — test read-replica consistency under write-heavy load. Monitor: query time percentiles, connection wait time, deadlock frequency.

How do you set performance testing thresholds and SLAs?

Base thresholds on: (1) Business requirements — "checkout must complete in under 3 seconds." (2) Current baseline — measure existing performance, set thresholds to detect regressions (e.g., p95 must not exceed 1.2x baseline). (3) Industry standards — Google recommends Z rps. Fail the build in CI if thresholds are breached.

What is the difference between vertical and horizontal scaling? How do you test for each?

Vertical: more CPU/RAM on a single machine — simpler but has a ceiling. Horizontal: more machines behind a load balancer — scales further but adds complexity (session management, data consistency). Test vertical: increase load until resources max out, note the ceiling. Test horizontal: verify load balancer distributes evenly, test with N and N+1 instances, verify auto-scaling triggers at the right threshold, and test instance startup time under sudden load.

How do you perform capacity planning based on load test results?

Process: (1) Establish current capacity — what load does the system handle within SLA thresholds? (2) Model growth — if traffic is growing 20% quarterly, when will current capacity be exceeded? (3) Test scaling scenarios — does adding 2x instances give 2x capacity (linear scaling) or less (bottleneck elsewhere)? (4) Identify the constraint — DB, network, CPU, or specific service. (5) Build a capacity model: users × avg requests per session × peak multiplier = required throughput. Re-validate quarterly.