Performance testing measures how a system behaves under load: response times, throughput, resource consumption, and stability. It is non-functional testing — the application may work perfectly for one user and collapse under a thousand.

Types of Performance Testing

• Load testing — expected traffic levels. Does the system meet response-time targets under normal peak load?
• Stress testing — beyond expected limits. Where does the system break, and does it fail gracefully or catastrophically?
• Spike testing — sudden traffic surges (a marketing campaign, a flash sale). Can the system absorb a 10x jump in seconds?
• Soak (endurance) testing — sustained load over hours or days. Detects memory leaks, connection pool exhaustion, and degradation over time.
• Scalability testing — how performance changes as resources are added. Does doubling servers double capacity?

Key Performance Metrics

1. Response time — measure p95 and p99 percentiles, not averages; averages hide the slow requests users actually feel
2. Throughput — requests per second the system sustains
3. Error rate — percentage of failed requests under load
4. Resource utilisation — CPU, memory, database connections, queue depths
5. Concurrency — simultaneous users supported within targets

The Performance Testing Process

1. Define targets — e.g. "p95 checkout response under 800ms at 2,000 concurrent users, error rate under 0.1%"
2. Model realistic scenarios — mirror real user behaviour mix (browse vs. search vs. purchase), not a single hammered endpoint
3. Prepare a production-like environment — undersized test environments produce misleading results
4. Execute incrementally — baseline first, then ramp load while monitoring
5. Analyse bottlenecks — correlate response degradation with resource saturation (database, CPU, network)
6. Tune and re-test — performance work is iterative

Common Performance Bottlenecks

• Unindexed database queries that degrade non-linearly with data volume
• N+1 query patterns hidden by ORMs
• Connection pool exhaustion under concurrency
• Missing caching on expensive computed responses
• Synchronous calls to slow third-party APIs in the request path

Tools

Popular open-source tools include k6, Apache JMeter, Gatling, and Locust. The tooling matters less than the scenario modelling — an unrealistic test passes while production fails. Performance testing pairs with functional coverage: see our complete software testing guide for how it fits the broader QA strategy.

Frequently Asked Questions: Performance Testing

When should performance testing happen?
Before any major launch, after architectural changes, and ideally continuously — a lightweight load test in the release pipeline catches regressions early, as described in our CI/CD testing strategy guide.

What is the difference between load testing and stress testing?
Load testing verifies behaviour at expected traffic; stress testing pushes beyond limits to find the breaking point and verify graceful failure.

How many virtual users do I need?
Derive it from analytics: peak concurrent sessions, plus growth headroom (commonly 2–3x current peak). Arbitrary round numbers waste effort or under-test.

Why do averages mislead in performance results?
A 200ms average can hide 10% of requests taking 5 seconds. Percentiles (p95/p99) describe what slow-path users actually experience.

Need a performance test designed and executed by specialists? Explore Astaqc's performance testing services or contact us.