Performance Testing

What it is

Performance testing measures how a system behaves under load: how fast it responds, how much throughput it sustains, and where it breaks. It is not one test but a family of profiles.

1
  VUs
2
   50 │        ┌──────────────┐        load / soak
3
      │       /                \
4
    0 └─────┘                  └──────►  time
5

6
  stress: ramp until it breaks    spike: sudden jump    soak: long steady run

The numbers that matter are latency percentiles (p50, p95, p99 — never just the average), throughput (requests per second), and error rate at each load step.

When to use it / when to avoid it

Use it for

Before a launch, sale or migration where traffic will step up sharply
Verifying an SLA or service-level objective (e.g. p95 < 300 ms at 1k rps)
Finding the saturation point and the first bottleneck (CPU, pool, lock, GC)
Checking memory or connection leaks with a sustained soak run

Avoid or reduce it when

The feature is still changing shape — optimise after the design settles
The environment is not representative (shared CI runner, laptop, cold cache)
You only read the average latency; percentiles are where the pain hides
You run a full soak on every commit — keep a fast smoke load in CI instead

Frameworks & tools

Tool	Ecosystem	Notes
k6	JS/TS	Scriptable in JavaScript, CLI-first, great CI story
Apache JMeter	Java / XML	GUI + CLI, huge protocol coverage, mature
Gatling	Java / Scala / Kotlin	DSL, excellent HTML reports
Locust	Python	Plain Python load scripts, distributed workers
vegeta	Go	Tiny CLI, constant-rate attack
NBomber	C# / .NET	Fluent .NET load tests
Artillery	Node.js	YAML scenarios, serverless-friendly
Grafana Cloud k6	SaaS	Hosted runs, dashboards

Quick setup

1
brew install k6        # or: docker pull grafana/k6
2
k6 run script.js

1
pip install locust
2
locust -f locustfile.py --headless -u 100 -r 10 -t 2m

1
go install github.com/tsenart/vegeta@latest
2
echo "GET http://localhost:8080/" | vegeta attack -rate=200 -duration=30s | vegeta report

1
<!-- Maven: Gatling -->
2
<dependency>
3
  <groupId>io.gatling.highcharts</groupId>
4
  <artifactId>gatling-charts-highcharts</artifactId>
5
  <version>3.11.5</version>
6
  <scope>test</scope>
7
</dependency>

1
dotnet add package NBomber

Example

1
import http from 'k6/http';
2
import { check, sleep } from 'k6';
3

4
export const options = {
5
  stages: [
6
    { duration: '30s', target: 50 },  // ramp up
7
    { duration: '1m',  target: 50 },  // steady
8
    { duration: '30s', target: 0 },   // ramp down
9
  ],
10
  thresholds: {
11
    http_req_duration: ['p(95)<300'],
12
    http_req_failed: ['rate<0.01'],
13
  },
14
};
15

16
export default function () {
17
  const res = http.get('http://localhost:8080/health');
18
  check(res, { 'status is 200': (r) => r.status === 200 });
19
  sleep(1);
20
}

1
from locust import HttpUser, task, between
2

3
class ApiUser(HttpUser):
4
    wait_time = between(0.5, 1.5)
5
    host = "http://localhost:8080"
6

7
    @task
8
    def health(self):
9
        self.client.get("/health")

1
echo "GET http://localhost:8080/health" | \
2
  vegeta attack -rate=200/s -duration=45s | vegeta report -type=text

1
import io.gatling.core.Predef._
2
import io.gatling.http.Predef._
3

4
class HealthSimulation extends Simulation {
5
  val httpProtocol = http.baseUrl("http://localhost:8080")
6
  val scn = scenario("health").exec(http("/health").get("/health"))
7
  setUp(scn.inject(rampUsers(50).during(30))).protocols(httpProtocol)
8
}

1
using NBomber.CSharp;
2
using NBomber.Http.CSharp;
3

4
var scenario = Scenario.Create("health", async context =>
5
{
6
    using var http = new HttpClient();
7
    var response = await http.GetAsync("http://localhost:8080/health");
8
    return response.IsSuccessStatusCode ? Response.Ok() : Response.Fail();
9
})
10
.WithLoadSimulations(Simulation.KeepConstant(copies: 50, during: TimeSpan.FromMinutes(1)));
11

12
NBomberRunner.RegisterScenarios(scenario).Run();

Anti-patterns & best practices

Report percentiles, not averages. Averages hide the slow tail that real users feel.
Match the environment. Test where the shape of the data, network and instance sizes resemble production, or the numbers mean nothing.
Fix one variable at a time. Change load, not also the build, so you can attribute the result.
Set thresholds in code. Fail the pipeline on p95 or error-rate regressions, not on a human eyeballing a graph.
Model think time. No pauses measures raw throughput, not user behaviour.
Watch the system, not only the client. Correlate load with CPU, memory, GC, pool saturation and downstream latency.