Blog
How to stress test your server properly
Stress testing your server is not about pushing traffic until something breaks. A proper test has a goal, a scope, a baseline, and a plan for what you will change afterward. This guide walks through a repeatable workflow teams use before launches, after infrastructure changes, and during capacity planning.
1) Define the goal before you start
Every useful stress test answers a specific question. Examples: “Can we handle 2× Black Friday traffic?”, “Did the new database tier remove the p99 spike?”, or “Where does latency climb when we add 500 concurrent users?” Without a goal, you collect numbers but cannot decide what success looks like.
- Capacity — find the maximum sustainable load before errors or SLA breach.
- Regression — compare today vs last release under the same scenario.
- Resilience — observe recovery after a spike or dependency failure.
2) Scope only what you own or are allowed to test
Stress testing must stay inside authorized boundaries. Document target IPs or hostnames, paths, time windows, and maximum concurrency. Notify stakeholders (SRE, DBA, security) so monitoring and on-call are aware. Never aim load at third-party services you do not control — that is not testing, it is abuse.
3) Establish a baseline in staging first
Run the same scenario at low load in staging and record p50 / p95 / p99 latency, RPS, error rate, CPU, memory, DB connections, and cache hit rate. Staging will not match production exactly, but it catches configuration mistakes and gives you a reference curve. Fix obvious issues before touching production.
4) Choose the right layer and traffic pattern
Match the test to what you need to validate. Layer 4 style load stresses network paths, firewalls, and connection tables. Layer 7 (HTTP/HTTPS) stresses application logic, auth, databases, and caches. Use a ramp to find the knee point, a spike to test autoscaling, and a soak run (30–60+ minutes) to expose leaks and pool exhaustion. See our L4 vs L7 guide for metric definitions.
5) Ramp gradually — do not jump to max instantly
Start at 10–20% of expected peak, hold for a few minutes, then increase in steps (e.g. +20% every 5 minutes). Note the load level where latency doubles or errors appear. That knee point is usually more actionable than the theoretical maximum. If something fails early, stop, fix, and rerun — do not keep hammering a broken system.
6) Watch the metrics that matter
- Latency percentiles (p50, p95, p99) — averages hide tail pain.
- Successful vs failed RPS — throughput without success rate is misleading.
- HTTP status and timeout distribution — 502/503 often point to upstream or pool limits.
- Resource saturation — CPU, memory, disk I/O, DB connections, queue depth.
- Dependency latency — API, cache, and database often fail before the web tier.
7) Run short production tests with guardrails
When staging is not representative, run limited production tests: off-peak windows, strict caps on duration and concurrency, feature flags to disable risky paths, and a rollback plan. Compare results to your baseline and stop as soon as you have enough data to answer the original question.
8) Turn findings into action items
A stress test is wasted if the report sits in a folder. File tickets for each bottleneck: slow queries, missing indexes, cache stampedes, undersized connection pools, rate limits, or CDN misconfiguration. Re-test after fixes to confirm improvement. Platforms like ipstress.st help teams run controlled scenarios from a hub, track concurrent runs, and iterate quickly — but the discipline of scope, ramp, and follow-up is what makes testing “proper.”
Quick checklist
- Written goal and success criteria
- Authorized targets and time window
- Baseline captured in staging
- Appropriate layer (L4 vs L7) and pattern (ramp / spike / soak)
- Dashboards and alerts ready before load starts
- Gradual ramp with a defined stop condition
- Post-test report with owners and re-test date