Load testing: how to find out whether your site can handle a rush of users

Load testing shows how many users a site can handle, how response times grow under load and what breaks first. It is run before sales, ad campaigns and launches, and after major architecture changes. Without it, teams usually learn the system's limit at the worst moment — when the customers arrive.

Here are the types of tests, how to build a realistic scenario, which metrics to watch and what to do with the results.

What types of load tests are there?

Load tests differ in the shape of the load and the question they answer. Several types are usually run: checking the expected load, finding the limit, checking sudden spikes and sustained operation.

Test type	Question	How it is run
Load	Will the system handle the expected peak	Ramp up smoothly to target load and hold it
Stress	Where is the limit and how does it fail	Increase load until failure
Spike	Can the system survive a sudden surge	Multiply load instantly
Soak	Are there memory leaks or degradation	Hold average load for hours

How do you build a realistic scenario?

A realistic scenario mimics real users: they do not open one page a thousand times, they browse the catalogue, search, add items to the cart and sometimes check out. Take action proportions from analytics and target load from past peaks plus a margin.

Preparation steps:

1. Pick three to five key user flows: catalogue browsing, search, cart, checkout, sign-in.
2. Take each flow's share and the pauses between actions from analytics.
3. Set a goal: for example, 500 concurrent users with p95 response time under 500 ms.
4. Prepare test data: users, products, promo codes.
5. Disable real payments, SMS and emails — replace them with stubs.

import http from 'k6/http'
import { sleep, check } from 'k6'

export const options = {
  stages: [
    { duration: '5m', target: 500 },
    { duration: '15m', target: 500 },
    { duration: '2m', target: 0 },
  ],
  thresholds: { http_req_duration: ['p(95)<500'], http_req_failed: ['rate<0.01'] },
}

export default function () {
  const res = http.get('https://staging.example.com/api/products?page=1')
  check(res, { 'status 200': (r) => r.status === 200 })
  sleep(Math.random() * 3 + 1)
}

Photo: Unsplash

Which metrics should you watch during a test?

Watch metrics from two sides: what users see — response time and error rate — and what happens inside — CPU, memory, database and queue load. Only together do they reveal the bottleneck.

• response time as p95 and p99 percentiles, not the average;
• error rate and error types: timeouts, 500s, refused connections;
• throughput — how many requests per second the system actually handles;
• resources — CPU, memory, disk and network on every server;
• database — slow queries, locks, connection count;
• queues — whether the number of waiting jobs is growing.

We covered collecting this data in monitoring and logging.

Where is the bottleneck usually found?

Most often the bottleneck is the database: slow queries without indexes, queries in loops and too few connections. Next come slow external services and missing caches for frequently requested data.

Typical findings:

• a query without an index that is invisible on test data and slow on real data;
• dozens of database queries per page instead of one;
• synchronous external API calls inside the user's request;
• no cache for the catalogue and home page;
• database connection or application process limits lower than needed.

How to deal with these: PostgreSQL indexes, caching web applications and job queues.

What do you do with the results?

From the results, list the bottlenecks in order of impact, fix the most serious one and rerun the test. Two or three iterations are usually enough to raise the system's limit several times over without buying new hardware.

• record baseline numbers to compare future tests against;
• fix one bottleneck at a time and recheck;
• write down the system's limit and an action plan for approaching it;
• add a short baseline test to CI to track regressions.

In short

• A load test reveals the system's limit and what breaks first.
• Test types: load, stress, spike and soak.
• The scenario mimics real users with proportions from analytics.
• Watch response time percentiles, errors and resources, especially the database.
• Fix bottlenecks one at a time and rerun the test.