Skip to content

Quality Assurance

Performance Testing Services

We find where your system breaks under load, on a Tuesday afternoon in a test, not on launch day in front of your customers.

Book a consultationTalk to us

What Performance Testing means in practice

Who it’s for: Teams facing a known traffic spike, running a system that slows under load, or needing to prove capacity before a launch, who would rather find the breaking point in a test than in an incident.

This is the service where we deliberately push your system until it struggles, so you learn where it breaks on your own schedule rather than during your busiest hour. We model realistic load, drive it at the system with the right tool, and read the results properly (which means percentiles, not averages), to tell you two things: how it behaves as traffic climbs, and where the first thing to give way actually is. That answer is almost never the thing teams assume it is.

The uncomfortable truth about performance is that most problems are architectural or in the database, not a shortage of servers. A test that turns up an N+1 query firing five hundred times per request, a connection pool capped at ten, a lock everything queues behind, or a cache that quietly stopped working tells you something you can fix cheaply. "Add more servers" is the expensive answer that often does not even work, because you cannot scale your way out of a bottleneck that every extra server also has to queue behind. We run the tests that find the real cause, then say plainly what the fix is, even when the fix is not more infrastructure.

Just as important is knowing when not to do this. Performance testing an unproven product is usually wasted effort: you spend weeks optimising a system whose shape will change the moment you learn what users actually do, chasing numbers that no requirement asked for. The point of this work is not a big impressive figure on a slide: it is meeting a real requirement, whether that is surviving a known launch spike, holding a p95 latency your customers feel, or proving you can carry the campaign traffic marketing has already booked. If you do not have a real target, we will help you set one before we test against it.

What you get

  • Realistic load scenarios modelled from your actual traffic (the journeys users take, the mix between them, and how they arrive), not a single endpoint hammered in isolation
  • Load, stress, soak and spike tests as your situation needs them, scripted in the right tool (k6, Gatling, JMeter or Locust) and version-controlled so they can be re-run
  • Results read on percentiles (p95, p99 and the tail), with the averages that hide your worst experiences called out for what they are
  • The bottleneck identified and named: the slow query, the N+1, the connection or thread pool limit, the lock, the memory leak, the saturated dependency, not just "it got slow"
  • Performance budgets and SLAs defined where you have none, and the system validated against them so "fast enough" becomes a number you can pass or fail
  • A prioritised findings report, what breaks first, at what load, why, and what to do about it, ordered by impact rather than by ease of fixing
  • Reusable test scripts and a way to run them, so performance becomes something you can check before each release rather than a one-off panic

What Performance Testing does for you

  • Find the limit before your customers do

    Every system has a point where it stops coping. The only question is whether you discover it in a controlled test on a quiet afternoon or in an incident during your highest-value traffic. Load, stress and spike testing move that discovery forward to a time and place you choose, with the logs, the profiler and an engineer watching, so the breaking point becomes a planning input rather than an outage.

  • Spend on the fix that actually works

    The instinct under load pressure is to buy more servers, and it is frequently the wrong instinct because most performance problems are architectural or in the database. A test that isolates the true bottleneck lets you spend on the change that removes it, often a query fix or a pool setting that costs nothing in infrastructure, instead of paying every month for capacity that just queues behind the same limit.

  • A number you can put in front of stakeholders

    Before a launch or a contract commitment, "we think it will hold" is not good enough. Testing against a defined budget turns a hope into evidence: this system carries this many concurrent users at this p95 latency, and here is the load at which that stops being true. That is something you can sign off, put in a runbook, and defend if anyone asks.

Why teams choose us for Performance Testing

  • You have a real deadline (a launch, a campaign, a known spike), and you need to know whether the system will hold, answered with evidence rather than optimism, in time to fix what will not.
  • Your system is slow or falling over under load and the team has been guessing at the cause; you want the actual bottleneck isolated and named before anyone spends money or effort on the wrong fix.
  • You want the results read honestly, on percentiles that represent your worst-served users, against a requirement that means something, not a vanity throughput figure detached from how anyone actually experiences the product.
  • You want a straight answer on whether you even need this yet, because performance testing an unproven product wastes effort, and you would rather be told that than sold a testing engagement you do not need.

What Performance Testing includes

The concrete pieces of work this covers, scoped to what your problem actually needs.

  • Load testing to expected volume

    Driving the system at the traffic you actually expect (the concurrent users, the request rate, the journey mix), to confirm it holds your latency and error-rate targets at that level with headroom to spare. This is the baseline question: at the load you are planning for, does the system behave, and how much margin sits between normal operation and trouble? It answers "will it cope on the day" with a measured yes or a measured no.

  • Stress testing to the breaking point

    Pushing load beyond the expected peak until the system degrades or fails, to find where the ceiling is and what it does when it hits it. The valuable part is often the failure mode: does it shed load gracefully, return honest errors and recover, or does it fall into a death spiral of retries and timeouts that takes everything down together? Knowing the ceiling and the behaviour at it turns a future outage into a known, planned-for boundary.

  • Soak and endurance testing

    Holding a sustained, realistic load for hours or days to surface the problems that only appear over time, memory leaks that slowly exhaust the heap, connection handles that are never released, disk or log growth, caches that grow unbounded, and the gradual degradation that a short test never runs long enough to reveal. Plenty of systems pass a twenty-minute test and fall over after six hours in production; a soak test finds that before your users experience it.

  • Spike and scalability testing

    Spike testing throws a sudden sharp jump in traffic at the system. The campaign email that lands, the doors opening on a sale, the traffic that arrives all at once rather than climbing gently: to see whether it absorbs the surge or buckles under it. Scalability testing measures how performance changes as you add load and as you add resources, which is what tells you whether the system actually scales or whether one shared bottleneck means more servers buy you nothing.

  • Bottleneck diagnosis and profiling

    A load test that only says "it got slow" is half a job. We instrument and profile under load to find the specific cause: the N+1 query pattern, the missing index, the connection or thread pool cap, the lock everything serialises behind, the saturated downstream dependency, the slow endpoint dragging a whole journey down. Naming the actual constraint is the difference between a fix that works and months of guessing, because relieving one bottleneck simply reveals the next.

  • Performance budgets and SLA validation

    We help define budgets and service levels where you have none. A p95 response time per key journey, an error-rate ceiling, a throughput floor: turning "it should be fast" into thresholds a test can pass or fail. Then we validate the system against them under realistic load, so performance becomes a checkable property rather than a subjective argument, and so a regression shows up as a failed budget rather than a customer complaint.

Where it fits

  • Proving capacity before a launch

    A system going live to a known audience. A new product, a migrated user base moving over at once, a service with a signed capacity commitment. The work is to establish the expected load, test to it and beyond, find where it breaks, fix what will not hold, and give you evidence you can carry the day. The goal is to walk into launch knowing the number, not hoping the number is fine.

  • Surviving a booked traffic spike

    Marketing has scheduled a campaign, a sale is dated, a seasonal peak like Black Friday is coming, or a press feature will land traffic all at once. Spike and load testing confirm whether the system absorbs a sudden surge that arrives faster than any autoscaler reacts, and expose the parts that buckle first (usually a checkout path, a login flow or a shared database), so they can be reinforced before the date rather than firefought on it.

  • Diagnosing a system that is already slow under load

    The application is fine when quiet and struggles when busy, and the team has been guessing at why. We reproduce the load, profile under it, and isolate the dominant bottleneck: frequently a database issue, an N+1 pattern or an exhausted pool rather than a shortage of compute. The deliverable is the named cause and the fix, so the next spend goes on what actually removes the constraint instead of on capacity that queues behind it.

  • Catching slow leaks with a soak test

    A system that runs cleanly for hours then degrades or restarts. The classic signature of a memory leak, a connection handle that is never returned, or an unbounded cache. A sustained endurance test holds realistic load long enough for the slow problem to surface and be traced, so the thing that was quietly forcing a nightly restart or a mysterious 3am page gets found and fixed rather than lived with.

How we approach Performance Testing

We start from the requirement, not the tool. Before scripting anything we agree what "fast enough" and "big enough" actually mean for you: the concurrent users you need to carry, the response time your customers will tolerate, the spike you know is coming, because a load test with no target is just an expensive way to generate graphs nobody can act on. If those numbers do not exist yet, defining them honestly is the first piece of work, and often the most valuable.

From there the whole discipline is realism. A load test is only as good as how closely it resembles what real users do, and testing the wrong scenario is worse than not testing at all because it hands you false confidence. So we model the real journeys, the real mix between them, real think-time and real data, then read the results at the percentiles that represent your worst-served users rather than the average that flatters you. When we find the bottleneck (and there is almost always one dominant one), we tell you what it is and whether the honest fix is a code change, a database change or, occasionally, more capacity.

How the engagement runs

We open with the target and the traffic, not the tooling. The first questions are what load you actually need to carry, what response time your users will tolerate, and what event you are testing for, because those fix the type of test, the scenarios and the success criteria. Then we study your real traffic: which journeys users take, in what proportion, how they arrive, what data they touch. That model is the whole foundation, because a test built on a wrong assumption about how people use the system produces confident numbers about a system nobody runs.

From there we script the scenarios in the right tool, run them against an environment that resembles production closely enough to trust (same shape of data, comparable infrastructure, external dependencies handled honestly), and ramp the load while we watch both the client-side results and the server-side internals. We read the output on percentiles, isolate the first thing that gives way, and take it to you with the cause named and the fix proposed. Where you want it, we leave the scripts and the means to re-run them, so performance stops being a one-off event and becomes a check you can repeat before each release.

How we design the tests and read the results

A load test is only ever as good as how realistic it is, and this is where most testing goes wrong. Hammering a single endpoint with identical requests, no think-time and a warm cache produces a large, reassuring number that means nothing, because no real user behaves that way. So we model the actual thing: the real distribution of journeys, the real ratio between browse and buy and search, realistic pauses between actions, a spread of data that defeats the cache the way genuine traffic does, and a load that ramps and varies rather than sitting flat. Testing the wrong scenario is worse than not testing, because it sends you into launch confident about a system you never actually exercised.

Reading the results is the other half of the craft, and the rule is simple: percentiles, never averages. An average response time is a comfortable lie: a mean of 200ms can hide a p99 of four seconds, which means one request in a hundred is a terrible experience, and at real volume that is a great many angry users and a tail that drags whole journeys down. We report p95 and p99 and watch the tail, because that is where your worst-served customers live and where cascading slowness begins. Alongside latency we track throughput, error rate and saturation, and we correlate the client-side numbers with server-side internals (CPU, memory, connection pools, query times, queue depths), because the response time tells you that something is wrong and the internals tell you what. That correlation is how a graph becomes a diagnosis instead of a mystery.

Resilience and behaviour under duress

Performance testing and resilience overlap more than people expect, because a system pushed past its limit is a system exposed. The way an application behaves when it is overwhelmed is a real property worth knowing: does it degrade gracefully, shedding load, returning honest errors quickly, protecting the core while the edges wait, or does it collapse into a spiral of retries, timeouts and connection exhaustion that turns a busy moment into a full outage? The same surge that a marketing campaign creates by accident is what a denial-of-service attempt creates on purpose, so a system that is understood and hardened against overload is more resistant to both. We look at whether timeouts, circuit breakers, rate limits and back-pressure are present and actually work under load, because a missing timeout somewhere deep in the stack is how one slow dependency takes the whole system down with it.

We also treat observability as part of the deliverable, because a performance problem you cannot see is one you cannot fix. If a test reveals that the system slows under load but the running system has no way to show which query, which endpoint or which dependency is responsible, then the next incident is diagnosed by guesswork under pressure. So where it is thin, we help put in the metrics, traces and load-correlated logging that turn "it is slow again" into a specific, located answer in minutes. The point of testing before launch is to remove surprises; the point of good observability is to remove them again the next time load changes in a way no test predicted.

Signs it’s time

  • A traffic spike is coming that you have not tested for. A launch, a marketing campaign, a seasonal peak like Black Friday, a press moment, or a migration that will move every user at once
  • The system already slows down or falls over under load, and you need to know why and where before it happens again in front of customers
  • You are about to launch and need to prove the system can carry the expected volume, capacity validation before the doors open, not a hopeful guess
  • You have a performance requirement or SLA in a contract and need to demonstrate, with evidence, that you actually meet it under realistic conditions

Our working method

The organising principle is that the goal is meeting a real requirement, not producing an impressive number. Everything follows from a defined target: the load to carry, the latency to hold, the spike to survive. Without one, testing generates graphs that no decision depends on, so if the target does not exist we help set it honestly before we test against it. And we will tell you when the honest answer is not to test yet, because performance testing an unproven product, whose shape will change the moment you learn how it is really used, is effort spent optimising something you are about to rebuild. Premature performance work is a real cost, and we would rather name it than bill for it.

When we do test, realism governs the scenarios and percentiles govern the reading, and diagnosis is treated as the actual deliverable rather than a graph handed over for someone else to interpret. We are also blunt about the fix. Most performance problems are architectural or in the database: an N+1, a missing index, a lock, an undersized pool, a broken cache, and the reflexive "add more servers" is often both expensive and useless because extra capacity still queues behind the same shared constraint. So we isolate the true bottleneck and name the change that removes it, even when that change is a query rewrite that costs nothing in infrastructure rather than the capacity purchase everyone expected to sign off.

Technologies we build it with

Chosen per problem, not per fashion. This is the stack we most often reach for on this work.

How we deliver

  1. 01

    Discover

    We map the system, the constraints and the business it serves, including the parts nobody documented.

    Architecture brief

  2. 02

    Architect

    Decisions get made, written down and defended before a line of production code exists.

    Decision records

  3. 03

    Build

    Short cycles against working software. You see progress in the product, not in a status deck.

    Shipping increments

  4. 04

    Operate

    Monitoring, incident response and iteration. The system is alive, so the engagement is too.

    Runbooks & SLOs

Want a straight answer on Performance Testing?

A short call with a senior engineer, before you write a brief. If Performance Testing is the wrong answer for your situation, we will say so and tell you what we think is right.

Book a consultationTalk to us

What changes

  • The breaking point, known

    A clear number for how much load your system carries before it degrades or fails, found in a test, so launch day holds no surprises.

  • The real bottleneck named

    The one thing that gives way first, identified specifically (the query, the pool, the lock, the leak), so you fix the cause instead of guessing.

  • Fast enough, proven

    Performance validated against a real budget on percentiles that reflect actual users, so "it feels fine" becomes a number you can pass.

Industries we serve

Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.

How pricing works

  • A fixed-scope performance engagement for a defined event. A pre-launch capacity validation, a Black Friday or campaign readiness check, an SLA verification, quoted once the target load, the scenarios and the environment are understood, so you are paying for a question with a clear answer rather than open-ended testing.
  • A focused diagnosis for a system that is already slow or failing under load, priced by the investigation: reproduce the load, profile under it, isolate and name the dominant bottleneck, and set out the fix in priority order.
  • An ongoing engagement where performance testing is built into your release process (budgets defined, scripts maintained, key journeys checked before each release), for teams who would rather catch regressions continuously than test in a panic before each peak.

Typical timeline

  1. 01

    Targets and traffic modelling

    A few days to a week agreeing what load and latency actually need to hold, and modelling the real user journeys, their mix and their data. The foundation the whole test depends on, and the step most likely to be skipped and most costly to skip.

  2. 02

    Scripting and environment setup

    Building the scenarios in the right tool and preparing an environment that resembles production closely enough to trust, realistic data shape, comparable infrastructure, external dependencies handled honestly rather than mocked into meaninglessness.

  3. 03

    Running the tests

    Load, stress, soak or spike runs as the situation needs, ramping load while watching both client-side results and server-side internals, reading everything on percentiles and isolating the first thing to give way.

  4. 04

    Diagnosis, fixes and handover

    The bottleneck named, the findings prioritised by impact, the fixes proposed and where wanted validated by a re-run, and the scripts plus the means to repeat them left with your team so performance stays a check rather than a one-off.

What working with us actually means

  • Senior engineers who read the internals

    Anyone can generate load; the value is in diagnosing what it exposes. The people running your tests have profiled systems under pressure and know where to look (the query plan, the pool, the lock, the leak), so the output is a named cause and a fix, not a graph that goes up and a shrug about why. No juniors handing you throughput numbers they cannot explain.

  • We operate what we build

    Because we run systems in production, we test for what actually hurts there: the tail latency real users feel, the failure mode under overload, the slow leak that surfaces at hour six. That operational instinct is why we read on percentiles rather than averages and why we care how a system behaves when it breaks, not just how fast it is when it is calm.

  • Honest about the fix and the need

    We will tell you when the real problem is the database rather than the server count, even though the infrastructure answer is easier to sell. And we will tell you when you should not be performance testing yet at all, because the product is too unproven for the effort to pay off. Straight answers about what to do (and what not to do), are the point.

  • Tests that outlast the engagement

    We leave you version-controlled scripts and a way to run them, so performance becomes a repeatable check before each release rather than a one-off you have to re-commission every time a peak approaches. A test you can only run once, run by people who have left, is barely a test at all.

How to engage us

Three ways to work with us on this, chosen to fit the problem, not our margin.

Related services

Part of Custom Software Development. Other work we do alongside this.

Common questions

Why do you insist on percentiles instead of average response time?

Because averages hide exactly the experiences that matter. A mean response time of 200ms can sit on top of a p99 of four seconds, which means one request in every hundred is a terrible experience, and at real volume that is a large number of frustrated users, plus a slow tail that drags whole journeys down when calls depend on each other. The average flatters you; the p95 and p99 tell you what your worst-served customers actually get. We report and act on the percentiles because that is where the real problems, and the cascading slowdowns, live.

Our system is slow under load, will you just tell us to add more servers?

Almost certainly not, because that is usually the wrong answer. Most performance problems are architectural or in the database: an N+1 query, a missing index, a lock everything queues behind, an undersized connection pool, a cache that stopped working, and adding servers does nothing when every extra server also queues behind the same shared bottleneck. We profile under load to find the actual constraint and name it, and only recommend more capacity when the evidence genuinely points there. Often the fix costs nothing in infrastructure and everything in knowing where to look.

How realistic does the test actually need to be?

Realistic enough that it exercises the system the way real users do, because a test is only as good as its resemblance to reality, and an unrealistic test is worse than none, since it hands you confidence in a system you never truly tested. Hammering one endpoint with identical requests and a warm cache produces a big meaningless number. So we model the real journeys, the real mix between them, real think-time and a spread of data that defeats caching the way genuine traffic does. Getting the scenario right is the single most important part of the whole exercise.

We are pre-launch with a new product, should we performance test now?

Often the honest answer is not yet. If the product is unproven and its shape will change the moment you learn how people actually use it, weeks spent optimising against guessed-at load is effort you will partly throw away, chasing numbers no real requirement asked for. The exception is when you have a genuine, dated capacity event (a launch to a known audience, a migration, a booked campaign), in which case validating you can carry it is exactly the right work. We will help you tell the difference rather than sell you a test you do not need.

What is the difference between load, stress, soak and spike testing, and which do we need?

Load testing drives the traffic you expect and confirms the system holds its targets there. Stress testing pushes past that until it breaks, to find the ceiling and see how it fails. Soak testing holds a realistic load for hours to catch slow problems like memory leaks that a short run never reveals. Spike testing throws a sudden sharp surge at it, like a campaign email landing all at once. Which you need depends on your situation: a Black Friday concern wants spike and stress, a system that degrades overnight wants a soak test, a pre-launch check usually wants load then stress. Agreeing that is part of the first conversation.

Thinking about Performance Testing?

Tell us the problem in your own words, not in requirements. A senior engineer reads it and comes back with a straight view on whether Performance Testing is the right answer here, or what would be.

  1. 01A senior engineer reads it. Not a form queue, and not an account manager.
  2. 02We reply either with questions or with a straight answer that we are not the right fit.
  3. 03If it looks like a fit, a technical call with the person who would actually run the delivery.
  4. 04Then scope, effort and risk in writing, before anyone signs anything.
Or book a free consultationPick a time that suits you. No pitch, no obligation.Prefer email? support@yarqat.com

Two fields required. We reply to real enquiries. No list, no sequence.