DEV Community: Elvin Aghalarov

Your average response time is lying to you (use p95 and p99)

Elvin Aghalarov — Thu, 22 Oct 2026 08:58:59 +0000

Your dashboard says average response time: 180 ms. Looks healthy. Meanwhile one in ten users waits almost a second. Here's why averages hide that, and what to use instead.

The math trick hiding in your dashboard

100 requests:

90 take 100 ms
10 take 900 ms

average = (90 × 100 + 10 × 900) / 100 = 180 ms

Nobody experienced 180 ms. Most people got a fast answer, some got a slow one, and the average describes neither group.

Now double the slow group to 20 requests: the average only moves to 260 ms. Still "fine" on a dashboard, while 1 in 5 users is having a bad time.

Percentiles say what users actually experience

A percentile answers: "how slow were the slowest X%?"

p50 (median): half of requests were faster. The typical experience.
p95: 1 in 20 was slower. Where people start to notice.
p99: 1 in 100 was slower. Sounds rare, isn't (see below).

For the example above: p50 = 100 ms, p95 = 900 ms. Two numbers that tell the real story.

Why p99 matters more than it sounds

A single page often makes many requests: API calls, assets, fragments. If a page makes 20 requests, the chance that at least one hits the p99 is:

1 − 0.99²⁰ ≈ 18%

Nearly one page view in five includes a p99-slow request. At scale, the tail is the user experience.

Compute them from your own data

You don't need an APM to start. If you log request durations, SQL does it:

-- PostgreSQL
SELECT
  route,
  count(*)                                                   AS requests,
  round(avg(duration_ms))                                    AS avg_ms,
  percentile_cont(0.50) WITHIN GROUP (ORDER BY duration_ms)  AS p50_ms,
  percentile_cont(0.95) WITHIN GROUP (ORDER BY duration_ms)  AS p95_ms,
  percentile_cont(0.99) WITHIN GROUP (ORDER BY duration_ms)  AS p99_ms
FROM request_log
WHERE created_at > now() - interval '1 hour'
GROUP BY route
ORDER BY p95_ms DESC;

Or in a few lines of JavaScript:

function percentile(values, p) {
  const sorted = [...values].sort((a, b) => a - b);
  const index = Math.ceil((p / 100) * sorted.length) - 1;
  return sorted[Math.max(0, index)];
}

const durations = [...Array(90).fill(100), ...Array(10).fill(900)];
console.log(percentile(durations, 50)); // 100
console.log(percentile(durations, 95)); // 900

⚠️ Never average percentiles across servers or time windows. The mean of two p95s is not a p95. Recompute from raw data, or use histograms that can be merged.

Why the tail moves first under load

As a system approaches capacity, the median often stays flat while the tail grows: requests start waiting in queues for a DB connection, a worker or a lock. A rising p95/p99 is usually the first warning that you're near the limit, well before the average or error rate changes.

Setting latency goals that work

Use p95 as the main goal: "p95 < 500 ms".
Add p99 for critical paths: login, checkout, search.
Always pair it with an error-rate goal. A fast 500 is still a failure, and a test that "passes" latency because errors return instantly is not a pass.
Set goals per endpoint: search can be allowed more than a page view.

In k6, that's:

export const options = {
  thresholds: {
    'http_req_duration{name:checkout}': ['p(95)<500', 'p(99)<1200'],
    http_req_failed: ['rate<0.01'],
  },
};

Compare runs, not single numbers

p95 = 420 ms alone means little. Against last week's identical run at 310 ms, it's a 35% regression worth catching before users do. Keep a baseline per test and compare every run with it.

TL;DR

Averages blend fast and slow users into a number that describes nobody.
Use p50 for typical, p95 for "noticeable", p99 for the tail.
Never average percentiles.
The tail rises first under load: it's your early warning.

I build Hoofbeat, which reports p50/p95/p99 per step and flags regressions against a baseline run. Original post on the Hoofbeat blog.

"Load, stress, spike, soak: four performance tests and the question each one answers"

Elvin Aghalarov — Thu, 22 Oct 2026 08:58:25 +0000

"We load tested it" can mean four very different things. Each test answers a different question, and running the wrong one gives you a confident answer to a question you didn't ask.

Test	Question	Shape	Length
Load	Do we meet our goals at expected traffic?	Ramp to peak, hold	10–30 min
Stress	Where and how do we break?	Keep increasing	Until it fails
Spike	Do we survive a sudden burst?	Instant jump	5–15 min
Soak	Do we stay healthy for hours?	Moderate, constant	2–24 h

All examples below use k6's ramping-arrival-rate executor, so the load is new users per second, which is how real traffic arrives. Only the stages change.

// shared setup
import http from 'k6/http';
export default function () {
  http.get(`${__ENV.BASE_URL}/products`);
}

1. Load test: "are we ready?"

Simulate the traffic you expect and check it against goals.

export const options = {
  scenarios: {
    load: {
      executor: 'ramping-arrival-rate',
      startRate: 0, timeUnit: '1s', preAllocatedVUs: 200, maxVUs: 2000,
      stages: [
        { target: 50, duration: '5m' },   // ramp to expected peak
        { target: 50, duration: '20m' },  // hold
        { target: 0, duration: '2m' },
      ],
    },
  },
  thresholds: {
    http_req_duration: ['p(95)<500'],
    http_req_failed: ['rate<0.01'],
  },
};

Clear pass/fail: thresholds hold or they don't. Run it before every launch and on a schedule after.

2. Stress test: "where's the ceiling?"

Keep increasing past expected traffic until something gives.

stages: [
  { target: 50, duration: '3m' },
  { target: 100, duration: '3m' },
  { target: 200, duration: '3m' },
  { target: 400, duration: '3m' },
  { target: 0, duration: '3m' },   // watch the recovery!
],

You learn two things:

The breaking point: the load where p95 or errors cross your limits.
The failure mode: graceful slowdown, clean 503s, or a cliff that takes minutes to recover from.

That last ramp-down stage matters: a system that doesn't recover on its own needs work, whatever its ceiling is.

3. Spike test: "what if we go viral?"

Real traffic doesn't ramp politely. Newsletters, Hacker News, a sale at 10:00 sharp.

stages: [
  { target: 10, duration: '2m' },    // normal
  { target: 300, duration: '10s' },  // spike
  { target: 300, duration: '5m' },   // hold
  { target: 10, duration: '1m' },
],

Spikes find what gentle ramps never do:

autoscaling that needs 3 minutes while the spike takes 10 seconds
cold caches sending everything to the database at once
pools sized for the average
one hot row (the stock count of the sale item) everyone writes to

4. Soak test: "can we run all week?"

Moderate load, held for hours.

stages: [
  { target: 30, duration: '5m' },
  { target: 30, duration: '4h' },
  { target: 0, duration: '5m' },
],

You're looking for drift: something that moves while the load doesn't.

memory that climbs and never plateaus → leak or unbounded cache
connections that slowly run out → resources not released on error paths
latency creeping up hour by hour → growing tables, fragmentation, GC pressure
errors at the same clock time → a cron job colliding with traffic

Compare the first hour's p95 with the last hour's. Healthy systems look boring.

Which one when?

Every pull request: a short, steady load test that catches regressions
Before every launch: load test at expected peak
Quarterly or after big changes: stress test to know your ceiling
Before known events: spike test shaped like the event
Before trusting a new service for weeks: soak test, overnight

TL;DR

Same user journey, four load shapes, four different questions. If you only ever ramp to peak and hold, you've answered "are we ready for a normal Tuesday?" and nothing else.

I build Hoofbeat, where all four are the same flow with a different load shape: schedule the soak overnight and get a Slack alert only if it regresses. Original post on the Hoofbeat blog.

Load testing a Laravel app without fooling yourself

Elvin Aghalarov — Thu, 22 Oct 2026 08:57:37 +0000

Laravel makes it easy to ship features fast, and just as easy to ship an N+1 query that only hurts at 200 concurrent users. Here's how to load test a Laravel app so the result actually means something.

1. Test production config, not your dev setup

The most common way to waste a load test is to measure the wrong thing.

❌ php artisan serve: single-threaded, one request at a time
❌ APP_DEBUG=true: collects debug data on every request
❌ Telescope or Debugbar recording
✅ PHP-FPM + Nginx, FrankenPHP, or Octane, same as production
✅ APP_ENV=production, APP_DEBUG=false
✅ caches built and OPcache on:

php artisan optimize   # config, routes, events, views

; php.ini (production)
opcache.enable=1
opcache.validate_timestamps=0
opcache.memory_consumption=256

And seed realistic data volumes: an index you don't need with 100 rows is essential with 1,000,000.

2. Handle CSRF like a browser does

Web routes need a CSRF token. A realistic test does what the browser does: load the form, read the token, post it back, keep the cookies. In k6:

import http from 'k6/http';
import { check } from 'k6';
import { SharedArray } from 'k6/data';

const users = new SharedArray('users', () => JSON.parse(open('./users.json')));
const BASE = __ENV.BASE_URL;

export default function () {
  const user = users[(__VU - 1) % users.length]; // a different account per virtual user

  const page = http.get(`${BASE}/login`);
  const token = page.html().find('input[name=_token]').attr('value');

  const res = http.post(`${BASE}/login`, {
    _token: token,
    email: user.email,
    password: user.password,
  });
  check(res, { 'logged in': (r) => r.status === 200 });

  // k6 keeps a cookie jar per virtual user, so the session continues:
  http.get(`${BASE}/orders?status=open`);
}

For API routes with Sanctum, log in once per virtual user, capture the token from the JSON response, and send Authorization: Bearer <token> on the following requests.

3. The usual Laravel bottlenecks

N+1 queries

// 1 query for orders + 50 queries for customers
$orders = Order::latest()->take(50)->get();

// 2 queries total
$orders = Order::with('customer')->latest()->take(50)->get();

Catch them before load testing does:

// AppServiceProvider::boot()
Model::preventLazyLoading(! app()->isProduction());

Too few PHP-FPM workers

pm.max_children caps concurrent requests. With 10 workers and 200 ms per request, you top out around 50 requests/second, with CPUs sitting idle.

max_children ≈ memory available for PHP ÷ memory per worker
e.g. 3 GB ÷ 60 MB ≈ 50

Idle CPU + rising latency = a pool is full.

Database connections

Every PHP worker can hold a connection: 4 servers × 50 workers = 200 connections, more than Postgres's default max_connections = 100. Use PgBouncer, or size both sides deliberately.

File-based sessions and cache

File locks serialize requests from the same user. Use Redis (or Valkey) for sessions, cache and queues.

Slow work inside the request

Emails, PDFs, webhooks, slow third-party APIs: queue them. And put a timeout on every outgoing HTTP call:

Http::timeout(5)->retry(2, 200)->post($url, $payload);

Password hashing at login

bcrypt and argon2 are designed to be slow. A login storm after a marketing email can saturate CPUs on its own. Test the login journey separately.

4. Read results per step

If only /orders slows down while login stays flat, it's that query, not "the server". Compare the p95 per step against a baseline run, fix one thing, run the identical test again.

TL;DR

Test production config: FPM/Octane, no debug, caches and OPcache on.
Script CSRF and tokens the way a browser does, with one account per virtual user.
Usual suspects: N+1, FPM workers, DB connections, file sessions, sync work, bcrypt.
Idle CPU + rising latency = a pool is exhausted.

Hoofbeat, the load-testing tool I build, is itself a Laravel app. Its flows handle the CSRF/Sanctum capture and per-user datasets for you, and can chart your Prometheus metrics next to latency. Original post on the Hoofbeat blog.

Load test your API before launch day (a one-afternoon checklist)

Elvin Aghalarov — Thu, 22 Oct 2026 08:56:58 +0000

Launch day is the worst time to find out how many users your API can serve. A load test a week earlier answers the same question while you can still act on it. Here's one you can run in an afternoon.

1. Write down what "ready" means

Three numbers, before you send a single request:

Expected peak: 2,000 visitors in the launch hour × ~30 API calls each ≈ 17 requests/s on average. Peaks run 2–3× higher, so plan for 50 requests/s.
Latency goal: p95 under 500 ms.
Error goal: under 1% failed requests.

These become pass/fail thresholds. Without them a load test produces charts, not a decision.

2. Test a journey, not an endpoint

Real users don't call GET /health in a loop. They:

POST /login, and keep the token
GET /products?page=1
GET /products/{id} for an id from the list
POST /cart with that product

Pass values from step to step, use many test accounts, and add think time between steps.

3. The script

A complete k6 version: ramp, hold, thresholds, chained requests, one account per virtual user.

import http from 'k6/http';
import { check, sleep } from 'k6';
import { SharedArray } from 'k6/data';

const BASE = __ENV.BASE_URL;
const users = new SharedArray('users', () => JSON.parse(open('./users.json')));

export const options = {
  scenarios: {
    launch: {
      executor: 'ramping-arrival-rate',
      startRate: 5,
      timeUnit: '1s',
      preAllocatedVUs: 100,
      maxVUs: 1000,
      stages: [
        { target: 5, duration: '1m' },   // warm up
        { target: 50, duration: '3m' },  // ramp
        { target: 50, duration: '5m' },  // hold at peak
      ],
    },
  },
  thresholds: {
    http_req_duration: ['p(95)<500'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const user = users[Math.floor(Math.random() * users.length)];
  const json = { headers: { 'Content-Type': 'application/json' } };

  const login = http.post(`${BASE}/login`, JSON.stringify(user), { ...json, tags: { name: 'login' } });
  check(login, { 'logged in': (r) => r.status === 200 });
  const auth = { headers: { ...json.headers, Authorization: `Bearer ${login.json('token')}` } };
  sleep(2);

  const list = http.get(`${BASE}/products?page=1`, { ...auth, tags: { name: 'list' } });
  const id = list.json('data.0.id');
  sleep(3);

  http.get(`${BASE}/products/${id}`, { ...auth, tags: { name: 'product' } });
  sleep(2);

  const cart = http.post(`${BASE}/cart`, JSON.stringify({ product_id: id }), { ...auth, tags: { name: 'cart' } });
  check(cart, { 'added to cart': (r) => r.status === 201 });
}

k6 run -e BASE_URL=https://staging.example.com launch.js

The tags: { name } let you read results per step instead of one blended number.

4. Run it against a copy of production

Same instance sizes, same config, realistic data volumes. If you must test production: quiet hour, start small, and check your host's rules (many want notice before load tests).

5. Read the result in this order

Errors first. A fast 500 is still a failure. Group by status code and step.
Percentiles, not averages. p95 and p99 per step (why).
The curve. Find the arrival rate where p95 starts climbing faster than the load: that's your practical capacity.

6. Fix the biggest thing, run it again

First tests almost always find one dominant bottleneck:

a missing index or an N+1 query
a connection or worker pool that's too small
an external API called without a timeout

Fix that one thing, run the identical test, compare the two runs side by side. Repeat until the thresholds pass with headroom.

TL;DR

Define peak, p95 goal and error goal.
Script a real journey with chained data and many accounts.
Warm up → ramp → hold.
Read errors → percentiles → curve.
Fix one bottleneck, rerun, compare.

I build Hoofbeat, where you can describe this journey in plain words instead of scripting it. It runs a smoke test first so you don't load a broken flow, and keeps every run to compare before and after. Original post on the Hoofbeat blog.

The same load test in k6, Locust, Artillery, Gatling and JMeter

Elvin Aghalarov — Thu, 22 Oct 2026 08:56:15 +0000

Comparison posts usually list features. Let's do something more useful: write the same test in five tools and see how each one feels.

The test: 50 new users arrive every second for 5 minutes, each requests /products. That's an arrival rate (open model), which is how real traffic behaves: new visitors keep coming whether or not your server is keeping up. (Why that matters.)

k6 (JavaScript)

import http from 'k6/http';

export const options = {
  scenarios: {
    browse: {
      executor: 'constant-arrival-rate',
      rate: 50,
      timeUnit: '1s',
      duration: '5m',
      preAllocatedVUs: 100,
    },
  },
  thresholds: { http_req_duration: ['p(95)<500'] },
};

export default function () {
  http.get('https://staging.example.com/products');
}

k6 run browse.js

Feels like: writing a small program. Thresholds are built in, so CI pass/fail is one line. Very efficient Go engine. Distributed runs need Kubernetes (k6-operator) or Grafana Cloud.

Locust (Python)

from locust import HttpUser, task, between

class Shopper(HttpUser):
    wait_time = between(2, 5)

    @task
    def browse(self):
        self.client.get("/products")

locust -f locustfile.py --host https://staging.example.com \
  --headless -u 500 -r 50 -t 5m

Feels like: plain Python, which makes complex user behaviour easy. Note the model: Locust spawns a fixed number of users (-u 500) that loop with think time, a closed model, so the request rate drops if the server slows down. A built-in web UI shows live charts.

Artillery (YAML)

config:
  target: https://staging.example.com
  phases:
    - duration: 300
      arrivalRate: 50
scenarios:
  - flow:
      - get:
          url: /products

npx artillery run browse.yml

Feels like: configuration, not code. Arrival rates are the default. Custom logic goes into JavaScript hooks, which gets messy for complicated flows.

Gatling (Java DSL)

import static io.gatling.javaapi.core.CoreDsl.*;
import static io.gatling.javaapi.http.HttpDsl.*;

import io.gatling.javaapi.core.*;
import io.gatling.javaapi.http.*;

public class BrowseSimulation extends Simulation {
  HttpProtocolBuilder httpProtocol = http.baseUrl("https://staging.example.com");

  ScenarioBuilder scn = scenario("Browse")
      .exec(http("products").get("/products"));

  {
    setUp(scn.injectOpen(constantUsersPerSec(50).during(300)))
        .protocols(httpProtocol);
  }
}

Feels like: a typed DSL with great HTML reports and very high throughput per machine. Natural for JVM teams; also available in Scala, Kotlin and JavaScript.

JMeter (GUI / XML)

No snippet that fits here: a JMeter test is a .jmx XML file you usually build in the GUI (Thread Group → HTTP Request → listeners), then run headless:

jmeter -n -t browse.jmx -l results.jtl

Feels like: the veteran. Supports almost any protocol (HTTP, JDBC, JMS, FTP, LDAP) with a huge plugin ecosystem. Thread Groups are closed-model by default; arrival rates need a plugin (Concurrency/Arrivals Thread Group). Large XML test plans are hard to review in pull requests.

Side by side

	Tests in	Default model	Distributed	Best for
k6	JavaScript	Both	k6-operator / cloud	Dev teams, CI
Locust	Python	Closed	Built-in workers	Python teams, complex behaviour
Artillery	YAML + JS	Open	Cloud runners	Quick scenarios, Node teams
Gatling	Java/Scala/Kotlin/JS	Both	Enterprise edition	JVM teams, very high load
JMeter	GUI / XML	Closed	Controller + workers	Exotic protocols

What none of them do for you

All five generate load well. What they leave to you:

Infrastructure: running enough machines, in the right regions, for big tests.
Realistic flows: chaining tokens, CSRF, per-user test data.
Interpretation: a wall of percentiles doesn't say why checkout got slow.

That gap is why I'm building Hoofbeat: describe the test in plain words (or import a HAR file, OpenAPI spec or Postman collection), and it runs on cloud load generators in the regions you pick, then explains the result per step. But if your team loves tests as code, k6 or Gatling are excellent choices, and many teams use a code tool and a hosted one side by side.

The longer comparison is on the Hoofbeat blog.

Concurrent users vs requests per second: the load test mistake that makes results look too good

Elvin Aghalarov — Thu, 22 Oct 2026 08:46:44 +0000

A requirement lands on your desk: "The system must support 10,000 concurrent users."

It sounds precise. It isn't. Depending on what those users do, it means anything from ~670 to ~12,000 requests per second. And the way most people then load test it hides the exact moment the system starts to fail.

Let's fix both.

Three numbers that get mixed up

Concurrent users: people with your app open right now. Most are reading, typing or thinking, not sending requests.
Requests per second (RPS): what your servers actually process. This is what burns CPU, DB time and connections.
Arrival rate: new users or sessions starting per second. This is how real traffic shows up.

Your servers never feel "users". They feel requests.

Converting users → requests

RPS = concurrent users × requests per user per minute ÷ 60

The "requests per user per minute" part is where everything hides:

	News site	Checkout flow
Time between clicks	~45 s	~5 s
API calls per click	3	6
Requests / user / min	4	72
RPS at 10,000 users	~670	~12,000

Before you test anything, pull two numbers from your analytics or access logs: how often users act and how many requests each action costs. Without them, "10,000 users" is not a requirement, it's a mood.

The bigger mistake: closed vs open load models

Load tools generate traffic in one of two ways, and they behave very differently when your system slows down.

Closed model: a fixed pool of virtual users

Each virtual user loops: send request → wait for the response → think → repeat.

// k6: 100 virtual users looping for 5 minutes (closed model)
export const options = {
  scenarios: {
    closed: { executor: 'constant-vus', vus: 100, duration: '5m' },
  },
};

Now imagine the server slows from 200 ms to 2 s per response. Every virtual user waits 10× longer before its next request, so the load drops by itself, right when the system is struggling. Your graphs show a slightly slower but "stable" system.

Real users don't do that. The person clicking "Buy" on their phone has no idea your server is having a bad minute.

This effect is called coordinated omission: the load generator coordinates with the system under test and silently omits the requests that would have hurt the most.

Open model: users arrive at a fixed rate

New users arrive at a set rate whether or not earlier ones are done:

// k6: 50 new iterations per second, regardless of response time (open model)
export const options = {
  scenarios: {
    open: {
      executor: 'constant-arrival-rate',
      rate: 50,
      timeUnit: '1s',
      duration: '5m',
      preAllocatedVUs: 200,
      maxVUs: 2000,
    },
  },
};

When the server slows down, work piles up, exactly as it would in production. That's the behaviour you need to see before launch.

Rule of thumb:

Public website or API → open model (arrival rate).
Genuinely fixed number of clients (200 internal workers, a fleet of devices polling every minute) → closed model is fine.

Little's Law: why a small slowdown becomes an outage

For any stable system:

requests in flight = RPS × average response time

RPS	Avg response	In flight
500	200 ms	100
500	800 ms	400
500	2 s	1,000

Same traffic, 10× the concurrent work. If your PHP-FPM pool has 100 workers, or Postgres allows 100 connections, the third row doesn't run slower: requests queue, latency grows further, more work piles up, and you're in a death spiral.

That's also why an open-model test is the one that finds your real limit: it's the only one where the in-flight count can grow like it does in production.

Setting the load for your test

Take the busiest hour from analytics, for example 54,000 sessions.
Convert it to an arrival rate: 54,000 ÷ 3,600 = 15 users/s.
Model the journey with realistic think time between steps.
Test at 2–3× the peak: 30–45 users/s.
Watch p95/p99 and error rate per step, not just averages.

TL;DR

"Concurrent users" is not a load. Convert it to requests per second with real usage data.
Closed-model tests (fixed looping users) back off when your system struggles, so the results look better than reality.
For public traffic, use an arrival rate (open model).
Little's Law explains why a 4× slowdown means 4× the in-flight work, and why pools run out.

I build Hoofbeat, a load-testing tool that supports both models (arrivals per second or a fixed number of users) and reports the requests per second actually achieved per step. The original post is on the Hoofbeat blog, along with how many users can my server handle?

How many users can your server actually handle? Measure it in an hour

Elvin Aghalarov — Thu, 22 Oct 2026 08:43:55 +0000

"How many users can this server handle?" comes up before every launch, and the usual answers are guesses: "a 2 vCPU box should do about 1,000 users."

That number means nothing. 1,000 people reading articles and 1,000 people checking out are completely different loads. But you can get a real number for your app in about an hour, and the method is the same for Laravel, Rails, Django, Node or Go.

Step 0: decide what "handle" means

Every server "handles" any load: it just gets slower until people leave. So pick limits first:

Latency: 95% of requests answer within 500 ms (p95 < 500 ms)
Errors: fewer than 1% fail
Stability: numbers stay flat for minutes, not just the first 30 seconds

Now capacity is a single number: the highest load at which all three still hold.

Why rules of thumb fail

Users aren't requests. A reader clicks every ~45 s; a shopper in checkout fires several API calls every few seconds:

	News site	Checkout flow
Time between clicks	~45 s	~5 s
API calls per click	3	6
Requests / user / min	4	72
RPS at 10,000 users	~670	~12,000

Same "10,000 users", 18× the load.

The bottleneck is rarely CPU. It's usually:

slow queries, N+1s, missing indexes, row locks
a pool that's too small: PHP-FPM max_children, Puma threads, Gunicorn workers, DB connections
an external API without a timeout holding workers hostage

Caching changes everything. Test what can't be cached: login, search, cart, dashboards.

Step 1: run a step test

Increase load in stages and hold each long enough to settle:

Step	Arrival rate	Hold
1	10 users/s	2 min
2	25 users/s	2 min
3	50 users/s	2 min
4	100 users/s	2 min
5	200 users/s	2 min

A few rules that make the result honest:

Each virtual user walks a real journey: home → search → product → login → add to cart.
Add think time (2–5 s) between steps, like a human.
Use many test accounts, not one. Otherwise you're benchmarking one cached DB row.
Use an arrival rate (open model), not a fixed pool of looping users (closed model). With a fixed pool, users wait when the server slows down and send fewer requests, so the load backs off exactly when things get bad. Real visitors don't coordinate with your server.
Test the production setup. Not php artisan serve, not npm run dev, not debug mode.

You can do this with k6, Gatling, Locust, Artillery, or a hosted tool. The method matters more than the tool.

Step 2: find the knee

Plot p95 latency and error rate against the arrival rate. You'll almost always see three zones:

Flat: latency barely moves. Headroom.
The knee: latency climbs faster than the load. Something is queueing.
Collapse: timeouts, 502s, 503s.

Your capacity is the last step before the knee where your limits still hold.

If p95 is 180 ms at 25 users/s, 240 ms at 50, then 1.4 s at 100, your answer is ~50 users arriving per second, not 100.

Translate it for the business: with 50 new visitors/s and an average visit of 4 minutes, that's about 12,000 people on the site at once (50 × 240 s). That's Little's Law, and it's the sanity check for everything above:

in-flight requests = requests per second × avg response time

At 500 RPS and 200 ms you have ~100 requests in flight. Let response time drift to 2 s and it's 1,000, which is more than most worker pools or DB connection limits. That's how a "small slowdown" becomes an outage.

Step 3: look at what bent at the knee

Put your server metrics on the same timeline as the test:

Idle CPU + rising latency → a pool is exhausted (workers, threads, DB connections)
CPU pegged → hashing at login, huge JSON serialization, rendering without caches
One endpoint slow, others flat → that endpoint's query: EXPLAIN ANALYZE it
too many connections errors → size the pool or add PgBouncer

Fix one thing, rerun the identical test, compare. Change three things at once and you'll never know which one helped.

TL;DR

Define "handle" as p95, error rate and stability limits.
Step test with real journeys, think time, many accounts and an arrival rate.
Capacity = last step before the latency knee.
Correlate the knee with server metrics, fix one bottleneck, repeat.

I build Hoofbeat, a load-testing tool where you can describe this kind of test in plain words and get the capacity verdict at the end. But the method above works with any tool. The original version of this post, plus guides on soak testing and finding bottlenecks, is on the Hoofbeat blog.