Knowledge Base / Cheat-sheets
Performance & Stress Testing
Load-test fundamentals, latency/throughput metrics & SLAs, test types (load, stress, spike, soak), environment & monitoring, and a dedicated tools roundup - five sections you can filter and toggle as you verify them. Progress is saved on this device.
What this checklist covers
Load Testing Fundamentals
The building blocks every performance test is assembled from: virtual users, ramps, and think time.
- A ramp-up period increases virtual users gradually, so the test measures behavior under rising load, not a simultaneous cold-start burst.
- A sustained plateau at target load (not just the ramp) is where most meaningful metrics are actually captured.
- Think time (pauses between requests) models real user pacing - a script with zero think time understates the concurrency a given user count really produces.
- Requests per second (RPS), not virtual-user count alone, is the number that actually matters to the system under test.
- A step-load profile (increasing load in discrete stages) makes it easy to spot exactly which stage a metric starts degrading at.
- A spike profile jumps load suddenly to test auto-scaling reaction time and burst-capacity headroom.
Metrics & SLAs
Reading results correctly - averages hide the experience your slowest users actually have.
- p95/p99 latency is tracked alongside the average, since the average can look healthy while a meaningful share of users have a bad experience.
- A latency distribution (not just a single summary number) reveals bimodal behavior - e.g. a fast cache-hit path and a slow cache-miss path.
- Error rate is tracked as its own first-class metric - a system that responds fast but wrong under load hasn't actually passed.
- Throughput (requests/sec successfully served) is reported alongside offered load, since the two diverge exactly at the point of saturation.
- A stored baseline from a known-good run is what a new run is actually compared against, not a gut-feel judgment of 'seems fine.'
- Performance budgets/thresholds are wired into CI so a regression fails the pipeline instead of surfacing weeks later in production.
Test Types & Scenarios
Load, stress, spike, and soak testing each answer a different question - naming them precisely keeps results interpretable.
- Load testing validates behavior at expected, real-world traffic levels - it answers 'does this hold up on a normal day.'
- Stress testing pushes past expected load deliberately to find the breaking point and observe how the system fails (gracefully vs. catastrophically).
- Spike testing checks recovery after a sudden traffic surge (a sale, a viral link) followed by a drop back to normal.
- Soak (endurance) testing runs for an extended duration to catch memory leaks, connection-pool exhaustion, or log-disk growth that only appear over time.
- Scalability testing increases load in tandem with added infrastructure to confirm capacity actually grows close to linearly, not sub-linearly.
- Autoscaling policies are tested directly under a load pattern designed to trigger scale-out and scale-in, not assumed to 'just work.'
Environment, Data & Monitoring
A performance number is only meaningful if the environment, data, and instrumentation behind it are trustworthy.
- The test environment matches production sizing (instance types, replica counts, network topology) as closely as possible - results from an undersized box don't transfer.
- Shared/noisy-neighbor test environments are flagged as a caveat on results, since concurrent unrelated load can silently skew numbers.
- The database is seeded to a production-representative row count and distribution - queries that are fast on 1,000 rows can fall over at 10 million.
- Test data is varied enough to avoid every virtual user hitting the same cached row or query plan, which would flatter cache-hit metrics.
- APM and infrastructure metrics (CPU, memory, DB connections, queue depth) are captured for the same time window as the load-test results, not reviewed in isolation.
- A single component under test at a time (app tier vs. DB vs. third-party API) makes it possible to isolate which layer is actually the bottleneck.
Performance Testing Tools
Load generators, cloud scaling services, and observability tools that make results reproducible and readable.
- k6 scripts load tests in JavaScript and is built for CI integration, with thresholds that can fail a pipeline automatically.
- Apache JMeter's GUI and huge plugin ecosystem make it a common default for teams that need protocol coverage beyond plain HTTP.
- Grafana k6 Cloud and BlazeMeter distribute load generation across regions, avoiding a single test runner becoming its own bottleneck.
- Azure Load Testing and similar managed cloud services integrate directly into CI/CD without self-hosting load-generation infrastructure.
- Grafana dashboards (often paired with Prometheus or k6's own metrics output) visualize load-test results alongside system metrics in real time.
- Datadog or New Relic APM traces a slow request down to the exact function or query, correlating it with the load test's timeline.
- LoadRunner remains common in large enterprises for its broad protocol support (legacy protocols, thick clients, ERP systems) beyond HTTP/HTTPS.
- Artillery is a lightweight, YAML/JS-configured option well suited for quick smoke-level load checks in a CI pipeline.