What is Performance Testing?

Types of performance test

• Load testing — the expected, realistic traffic (average and peak) to confirm the system meets its response-time and error targets under normal conditions.
• Stress testing — traffic pushed beyond the expected peak until something breaks, to find the limit and see whether the failure is graceful (slow, 503s) or catastrophic (crashes, data corruption).
• Spike testing — a sudden jump from low to very high traffic, as in a marketing campaign or a flash sale, to check autoscaling and queueing.
• Soak (endurance) testing — moderate load for hours or days, to catch memory leaks, connection pool exhaustion and disk growth that short tests never show.
• Scalability testing — increasing load in steps to learn how throughput and latency change as resources are added.
• Benchmarking — a quick, repeatable measurement of one endpoint to compare two versions or two implementations.

Try it: HTTP Request Benchmark Try it: API Performance Comparator

The metrics that matter

• Response time — measured per request. Report percentiles, not the average: p50 (median), p95 and p99 tell you what most users and the unluckiest users experience. An average hides the slow tail.
• Throughput — requests per second (or transactions per second) the system sustains.
• Error rate — percentage of requests that fail (5xx, timeouts, connection errors). It must stay near zero at the target load.
• Concurrency — how many virtual users or open connections are active at once.
• Resource usage — CPU, memory, database connections, queue depth on the server side, correlated with the load timeline.
• Apdex or SLO compliance — the share of requests inside the agreed budget (for example 95% under 300 ms).

Try it: Response Time Analyzer Try it: Response Size Analyzer

Planning a first performance test

• Define the goal as a number: "checkout completes in under 800 ms at p95 with 500 concurrent users and less than 0.1% errors".
• Pick the critical journeys — login, search, add to cart, checkout, the top three API endpoints — rather than every page.
• Model realistic traffic: the mix of journeys, think time between actions, ramp-up and steady state. Use production analytics if you have them.
• Prepare test data at scale: thousands of distinct users, products and payloads so caches and unique constraints behave as in production.
• Run in an environment that resembles production in size, or scale the results deliberately. A laptop-sized database will not tell you about a production one.
• Establish a baseline first with a single user, then ramp. Compare every later run against the baseline.
• Monitor the server side during the run; the client-side numbers alone cannot tell you why it got slow.

Try it: Load Test Data Generator Try it: Concurrent Request Test Generator

Tools: JMeter, k6, Gatling and browser tools

Apache JMeter is the long-standing open-source choice with a GUI, recorders and CSV data sets; k6 is script-based (JavaScript), lightweight and CI-friendly; Gatling is Scala/Java-based with excellent reports; Locust is Python-based. Cloud services (BlazeMeter, Grafana Cloud k6, Azure Load Testing) run the same scripts from many regions.

A browser cannot generate production-scale load, but browser tools are ideal for the steps around a load test: measuring a single endpoint's response time distribution, comparing two endpoints, checking payload size and compression, and generating the CSV and JSON data files the runners consume.

Try it: JMeter Test Data Generator Try it: JMeter CSV Generator Try it: HTTP Request Benchmark

Reading the results

• Latency rising while throughput flattens means a bottleneck was reached — CPU, a database, a connection pool or a downstream API.
• Error rate climbing before latency does often means a limit (max connections, rate limit) rather than slowness.
• p99 far above p95 points at garbage collection pauses, lock contention or a slow dependency hit by a few requests.
• Slow degradation during a soak test is a leak: memory, file handles or connections.
• A result that cannot be reproduced on a second run is noise; fix the environment before tuning the code.

Try it: API Performance Comparator Try it: Cache Header Analyzer

Common mistakes

• Testing with one user id or one product — everything hits the cache and the numbers are fantasy.
• Ramping to full load instantly, then blaming the system for a spike it was not designed for.
• Reporting averages. Always report p95 and p99 with the error rate.
• Running the load generator on the same machine as the system under test.
• Ignoring payload size: a 2 MB JSON response is slow no matter how fast the server is.
• Testing once before launch and never again. Performance regresses one commit at a time.

Try it: Response Size Analyzer Try it: Load Test Data Generator

Frequently asked questions