A shortlist in 72 hours, contributing inside two weeks, and a 30-day guarantee if the fit is wrong.
72-hour shortlist · 30-day replacement guarantee · Month-to-month
The most common load test we see runs a thousand virtual users against one endpoint, with the same account, requesting the same record, as fast as the generator can manage.
It passes comfortably. It also tells you nothing, because the second request onwards was served from cache, the database was barely touched, and no real user behaves like that. What has been measured is how quickly your infrastructure can return a cached response — a number nobody needed.
Real traffic is uneven. Users pause between actions. They touch different records, so caches miss. They arrive in bursts. They do the expensive things — search, report generation, checkout — at the times they are most likely to collide. A test that does not reproduce that shape is not a smaller version of production. It is a different workload that happens to use the same URLs.
And the deliverable is not a pass. The useful output is the point at which the system breaks, what breaks first, and what the number was when it did.
Most load tests we are asked to review are measuring something other than what the team believes.
Building from production traffic data — request mix, think time, data spread — rather than hammering one endpoint with one account.
Reporting at the percentile the business actually cares about, and knowing why a mean response time is close to useless.
Awareness that a generator waiting on a stalled system stops recording the worst latencies, and designing so that does not happen.
Tying response times to CPU, memory, pools and query behaviour so the output is a diagnosis rather than a graph.
Treating the breaking point and the first component to fail as the deliverable, rather than reporting that a target was met.
A live conversation in English, every time. Performance findings usually need explaining to people who own the deadline.
Bad performance testing is worse than none, because it produces documented confidence.
A team tests to twice expected peak, passes, and plans a launch around it. The first real busy hour arrives and the system falls over at sixty per cent of the tested figure. Nothing was faked — the test simply used a handful of accounts, so every query hit rows that were already in cache and never exercised the lock contention that real concurrent users on different records produce.
Measurement error hides the rest. Reporting an average response time conceals precisely the behaviour that matters: if the average is 200ms and the 99th percentile is nine seconds, one request in a hundred is failing a user, and the average will never show it.
Worse, most load generators wait for a response before sending the next request from that user. When the system stalls, the generator stalls with it and simply stops issuing the requests that would have recorded the worst latencies. The stall is therefore under-represented in your own results, and the graph looks better precisely when behaviour was worst. Engineers who have been caught by this design around it. Engineers who have not will show you a clean percentile chart from a run that included a four-second freeze.
The third failure is a scaled-down environment and linear extrapolation. Half the infrastructure does not give you half the capacity — connection pools, caches and locks do not scale proportionally, and the extrapolated number is fiction presented as a forecast.
Performance Tester (2–4 years). Executes tests using established scripts and reports results. Comfortable with the tooling. Needs direction on scenario design and interpretation.
Senior Performance Engineer (4–7 years). Designs realistic scenarios from production traffic data, correlates client-side results with server-side metrics, and identifies the actual bottleneck rather than reporting that it was slow.
Performance Lead (7+ years). Owns capacity planning with the business, sets the performance budgets features must meet, builds testing into delivery rather than before releases, and can say when a target is not worth what it costs to reach.
Pre-launch validation. A campaign, a migration or a seasonal peak with a fixed date. The most common request, and the most deadline-driven.
Diagnosing production slowness. Reproducing a problem under controlled load so it can be fixed rather than guessed at.
Capacity planning. Establishing where the ceiling is and what it costs to raise it, before somebody commits to a growth number.
Building it into the pipeline. Moving from occasional projects to regression tests that catch a slowdown when it is introduced. Overlaps with QA automation engineers.
Soak testing. Long runs that surface leaks and resource exhaustion invisible in a thirty-minute test.
Week one. They ask for production traffic data before writing a script — request mix, arrival pattern, and the distribution of what users actually touch. If nobody has that, establishing it is the first deliverable, because everything after depends on it. Expect questions about what response time the business considers a failure, at which percentile.
Weeks two to four. A scenario that resembles real usage, run against an environment whose relationship to production is documented, with results correlated to server-side metrics. The output should name the first thing that breaks and at what load, not report a pass.
The warning sign is a report with only client-side numbers. Response times without matching CPU, memory, connection pool and database metrics tell you something got slow and nothing about why. Somebody who has not asked for access to your monitoring is going to hand you a graph and no diagnosis.
Testing with one account and one record. The most common design flaw, and it invalidates the whole exercise. Real users spread across data, which is what produces cache misses and lock contention. Parameterise from a realistic data set or you are load testing your cache.
Reporting averages. The average hides the tail, and the tail is the user experience you are being asked about. Report percentiles, agree in advance which one the business cares about, and be sceptical of any performance summary that leads with a mean.
Extrapolating from a scaled-down environment. Contention does not scale linearly, so doubling a result from half-sized infrastructure produces a number with no relationship to reality. If you must test small, say what the result does and does not support — and resist the request to turn it into a capacity figure.
Testing once, before launch. Performance regresses through ordinary change: a query that lost its index, a new call inside a loop, a payload that grew. A single pre-launch test certifies one build. Catching regressions requires running regularly against a known baseline, which is a change in process rather than a bigger test.
Rates depend on seniority, environment complexity, and engagement length. Tell us the role and we will give you a firm number.
Tell us the role and we will send a shortlist within 72 hours.
Tell Us the RoleTell us the role. Three to five profiles within 72 hours.