Performance Testing Without the Complexity
What p50/p95/p99 actually mean, when load testing differs from stress testing, and how to set meaningful thresholds without a dedicated performance engineer.
Performance testing has a reputation for requiring specialist knowledge, dedicated tooling, and weeks of setup. Most teams skip it as a result — and then discover their performance issues in production under real load, which is the worst possible time.
VigilQA's performance module is designed to make the common cases approachable without a performance engineering background. Here's the conceptual grounding you need to use it well.
Understanding percentile metrics
p50 (median) — half of requests complete faster than this. This is your "typical" user experience.
p95 — 95% of requests complete faster than this. This is your "almost everyone" threshold — the experience your users reliably get.
p99 — 99% of requests complete faster than this. This is your worst-case experienced by real users at scale.
Why not just use average? Because averages hide outliers. An average response time of 200ms sounds fine — but if 1% of requests take 10 seconds (included in that average), 1% of your users are bouncing. p95 and p99 expose those tail latencies.
The four test types
- Load test — ramp up to expected production traffic and hold it. Answers: "does the system handle normal load without degrading?"
- Stress test — push beyond expected load until something breaks. Answers: "what's the breaking point, and how does it fail?"
- Spike test — sudden large burst of traffic, then back to normal. Answers: "can the system handle a viral moment or a flash sale?"
- Soak test — moderate load held for a long time (hours). Answers: "are there memory leaks or resource exhaustion issues that only appear over time?"
Setting thresholds that mean something
The most common mistake in performance testing is setting thresholds arbitrarily — "p95 under 500ms" — without tying them to user experience or SLAs. Before you set a threshold, ask: "what response time causes a user to perceive the app as slow?" Research consistently shows the answer is around 300ms for web interactions, 1–2 seconds for full page loads.
VigilQA lets you define pass/fail thresholds per endpoint — so a search endpoint that's expected to be slow has a different threshold than a simple data fetch.
Starting small
You don't need to test everything on day one. Start with your highest-traffic endpoints and your most latency-sensitive user flows. Add a load test to CI that runs weekly — not on every commit, since it takes time — and use the dashboard to track trends over releases. Sudden p99 regressions are the signal you're looking for.