Book 10 · Testing & QualityPage 18 of 36

Performance Testing

In Turkish: Performans Testi
Pronunciation: per-FOR-munss TES-ting

Updated October 3, 20262 min read

In short

Performance testing measures how fast, stable and scalable a system is under expected and extreme load, from response times to its breaking point.

What is performance testing?

Performance testing is an umbrella for several kinds of tests. Load testing checks behavior under the expected traffic; stress testing pushes beyond it to find the breaking point; spike testing applies a sudden surge, such as a ticket sale opening; soak or endurance testing runs a steady load for hours to reveal memory leaks and slow degradation; and scalability testing checks how performance changes as resources are added.

The key measurements are latency, usually reported as percentiles such as p95 and p99 rather than averages, throughput in requests per second, error rate, and resource use such as CPU, memory and database connections. Clear targets, such as "p95 under 300 ms at 500 requests per second", turn the results into pass or fail.

Tools such as k6, JMeter, Gatling and Locust simulate many users with scripts that follow realistic journeys. Tests should run against an environment that resembles production, with realistic data sizes, and be repeated after major changes, ideally as part of a scheduled pipeline, so regressions show up before users notice them.

A common misconception is that performance testing only happens just before launch. Discovering then that the database design can't scale is the most expensive moment to find out. Small, regular performance checks during development, together with profiling and production monitoring, catch problems while they are still cheap to fix.

Key takeaways

Performance testing measures speed, stability and scalability under load.
It includes load, stress, spike, soak and scalability tests.
Track percentiles such as p95 and p99, throughput and error rate.
k6, JMeter, Gatling and Locust are common tools.
Test regularly in a production-like environment, not only before launch.

Example

A load test with a pass/fail target (k6)javascript

import http from "k6/http";
import { check, sleep } from "k6";

export const options = {
  stages: [
    { duration: "1m", target: 200 },   // ramp up to 200 virtual users
    { duration: "5m", target: 200 },   // hold the load
    { duration: "1m", target: 0 },     // ramp down
  ],
  thresholds: {
    http_req_duration: ["p(95)<300"],  // 95% of requests under 300 ms
    http_req_failed: ["rate<0.01"],    // fewer than 1% errors
  },
};

export default function () {
  const res = http.get("https://staging.example.com/api/products");
  check(res, { "status is 200": (r) => r.status === 200 });
  sleep(1);
}

Readers ask

What is the difference between load testing and performance testing?

Performance testing is the umbrella term. Load testing is one type of it, checking the system under the expected amount of traffic. Stress, spike and soak tests are other types.

Why use percentiles instead of average response time?

Averages hide slow requests. A p95 of 300 ms means 95% of requests were faster than that, which shows what most users experience and exposes the slow tail that an average smooths over.

Where should performance tests run?

In an environment as close to production as possible, with similar hardware, configuration and data volumes. Results from a developer laptop rarely predict production behavior.