Load and performance testing before the date that matters

What this actually solves

This service is almost always bought because of a date. A sale is coming, a television or radio spot is booked, an investor demo is on Thursday, or last year the site went down on the busiest day of the year and nobody has forgotten it. The question is never really "is it fast" — the question is "will it still be standing at eight o'clock on Friday evening", and nobody in the building can answer it because nobody has ever measured.

The second reason is quieter and costs more over time. A team notices the system is slow under load, cannot say why, and starts buying capacity. Bigger instance, more workers, another cache. Sometimes it helps. Often it changes nothing, because the constraint was one query, or a connection pool ceiling, or an external service everything waits on. Load testing exists to replace that guessing with a name. A system has one narrowest point at any given moment, and widening anything else is money burned.

There is a measurement point underneath all of this that decides whether a report is worth reading. Averages lie. A slow tail disappears inside an average, because the requests answered quickly outnumber the ones left waiting and pull the headline number back down, and it is the customers who waited who have already gone. The industry works in percentiles for exactly this reason — p95 and p99, the times that the slowest tail actually experienced. Any performance report handed to you in averages is hiding its worst result inside its headline.

How the work runs

1. Agree the target, from your data. If you cannot already say how many concurrent users to plan for, we derive it — last year's peak hour from your analytics, this year's expected multiple, converted into concurrent virtual users and a ramp shape. This conversation decides everything downstream and it is where the honest disagreements happen. One to two days.
2. Permission and pre-flight questions, in writing. A named approver, a date, a time window. Alongside it the questions that decide whether the result will mean anything — is there rate limiting, is there a web application firewall that will start blocking us, is a CDN caching the responses we intend to measure, and how far does staging differ from production in size and data volume. One day, mostly waiting on answers.
3. Choose the routes that actually load the system and script them. Not the homepage, which is usually cached and proves nothing. Search, login, cart, checkout — the paths that hit the database and the application. Scripts are written in k6 with realistic pauses between requests so the simulated traffic behaves like people rather than a flood, and with pass and fail thresholds embedded so the run judges itself. Two to four days.
4. Baseline, then load, then stress — and spike or soak where the traffic warrants it. Baseline first so there is something to compare against. Then the agreed level. Then deliberately past it, to find the breaking point. A spike run if your traffic arrives in sudden bursts from advertising or an email send. A soak run of several hours if the system has to survive unattended over a weekend, because memory leaks, filling log volumes and exhausted connection pools only appear with time. Two to five days.
5. Watch the server side while the load runs. Without CPU, memory, database and queue metrics from inside, you are only pushing from outside and guessing at what gave way. This is what turns a graph into a diagnosis. Runs alongside step four.
6. Report and recommendations. Numbers in percentiles with throughput and error rates, the breaking point stated plainly, the bottleneck named, and three recommendations in priority order — written so a non-technical owner can act on them. One to two days.

What moves the price

The range is $800–$10,000 over 1–4 weeks, and three factors decide where you sit.

How many flows are in scope. One route, one report, one verdict is a small engagement. Search, cart, checkout, login and an API under separate profiles is a much larger one, because each needs its own script, its own data and its own interpretation.

Whether server-side investigation is included. Measuring from outside tells you the system slowed down. Reading the database, the query plans and the resource metrics tells you what slowed it down. The second is more valuable and it is more work.

Whether re-testing after fixes is included. Quoting for a single pass is cheaper and frequently incomplete, because fixing the first bottleneck reveals the second. If the date you are preparing for is fixed, budget for at least one re-run.

What usually goes wrong

A test is fired at production without written authorisation. It is the fastest way to turn a helpful exercise into an incident. Real customers are locked out mid-transaction, the provider may treat the traffic as an attack and null-route it, and responsibility lands on whoever pressed the button. Permission in writing, naming a window, every time, with no exceptions for urgency.

The report is written in averages. An average response time is the most quoted and least useful number in this field. It conceals precisely the customers who are having a bad experience and leaving. Percentiles, always, and error rate alongside them — a system that looks fast because it is failing quickly is a real and regularly missed result.

The load is generated from one laptop on a home connection. Virtual users generated from a single machine on ordinary broadband saturate its uplink long before they trouble the server, and the conclusion drawn is that the system is slow when what was measured is the tester's own internet. Generation has to come from an environment that can actually produce the traffic, and the test setup itself has to be ruled out before any finding is reported.