Performance Testing Services

Why performance testing matters

Slow software costs money. Users abandon slow pages and checkouts, APIs time out under load and infrastructure bills climb when inefficient code is scaled with hardware. Worst of all, performance problems often appear at the most important moments — a product launch, a marketing campaign or Black Friday.

Performance testing simulates realistic traffic in a controlled way, measures how the system responds and pinpoints the components that limit capacity, so you can fix them in advance.

Problems we solve

• Uncertainty about whether the site will cope with a launch or campaign
• Response times that degrade as data grows
• Previous outages during traffic spikes
• High cloud costs with unclear cause
• Performance complaints that are hard to reproduce

What’s included

Designing realistic tests

Useful performance tests model real behaviour: the mix of pages and API calls users make, think time between actions, realistic data volumes and the geographic spread of traffic. We base scenarios on your analytics and logs, agree targets such as “95% of checkout requests under 800 ms at 2,000 concurrent users”, and run tests against a production-like environment.

From results to fixes

A performance report is only useful if it leads to action. We correlate load test results with server, database and application metrics to find the true bottleneck — often a missing index, an N+1 query, an undersized connection pool or a slow third-party call — and recommend or implement fixes, then retest to confirm the improvement.

Types of performance tests

Setting performance targets

Tests need targets to pass or fail against. Useful targets are specific and tied to user experience:

• Response time at the 95th or 99th percentile, not just the average — averages hide slow experiences.
• Throughput: requests or transactions per second at peak.
• Error rate under load, typically aiming for near zero.
• Resource headroom: CPU, memory and database connections at peak.
• Front-end measures such as Core Web Vitals for public websites.

Base targets on real analytics where possible — current peak traffic, growth plans and known events — and add a safety margin. Then run the most important tests regularly in your pipeline so regressions are caught before they reach users, rather than in a one-off test before launch.

Common performance bottlenecks

Performance testing tools compared

We choose based on your team’s language, protocols and the scale required.

A performance testing engagement, step by step

1. Agree goals1–3 days

   Define user journeys, expected traffic, peak events and response-time targets with your team.

2. Prepare the environment2–5 days

   Use a production-like environment and realistic data volumes; agree monitoring access.

3. Script and baseline3–7 days

   Build test scripts and measure today’s performance at normal load.

4. Load, stress and soak runs1–2 weeks

   Increase load step by step, push past expected peaks and run long tests to expose leaks.

5. Analyse and fixvaries

   Correlate results with metrics and traces, recommend fixes and re-test to confirm improvement.

What the final report includes

• Test scenarios, load profiles and environment details
• Response-time percentiles (median, 95th and 99th) for each key transaction
• Throughput and error rates at each load level
• The point at which performance degrades and the resource that limits it
• Prioritised recommendations with expected impact
• Scripts handed over so you can repeat the tests

Performance testing pitfalls

• Testing against an empty database. Queries that are fast with 1,000 rows can be slow with 10 million.
• Looking only at averages. Averages hide the slow requests users notice; use percentiles.
• Generating load from one machine that becomes the bottleneck itself.
• Ignoring third-party limits. Payment, email and mapping APIs often have rate limits; mock or coordinate them.
• Testing once. Performance regresses quietly; schedule smaller tests regularly and before major releases.

Making performance part of everyday delivery

One-off load tests are valuable before launches and peak seasons, but the most resilient teams also add small performance checks to their pipeline and keep production monitoring in place. We can add lightweight load tests to your CI/CD pipeline and set up the observability described in our site reliability engineering service.

Front-end performance matters too

Server response time is only part of the story. Users judge speed by how quickly a page becomes visible and usable, which depends on images, JavaScript, fonts and third-party scripts. We measure Core Web Vitals — Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift — on real devices and slow networks, and recommend fixes such as image optimisation, code splitting, caching and deferring non-essential scripts.

Preparing for peak events

Product launches, marketing campaigns, seasonal sales and enrolment deadlines all bring sudden traffic spikes. We work back from the expected peak: estimate concurrent users and request rates, test well above that level, confirm auto-scaling reacts quickly enough, check database connection limits and caches, and agree a runbook for the day itself — who watches which dashboards and what to switch off first if the system struggles.

Related services

Part of QA & testing. Related: site reliability engineering and cloud & DevOps.

This page is part of QA & Software Testing Services — see the full overview for related services, approach and pricing.