Support service
Stay fast on your busiest day
When a campaign, a launch or month-end brings the system down, the cause is rarely where it seems. We measure the real load, find the bottlenecks and fix them, with before and after numbers.
- Duration
- 2 to 8 weeks
- Model
- Measure, fix, measure again
- Output
- Lasting fixes and measured results
Signs performance is a structural problem
Occasional slowness is normal. These patterns are not; they point to limits in the design rather than a bad day.
- The system slows down or fails on campaign days, launches or month-end, and recovers when traffic drops.
- Average response times look fine, but the slowest one percent of requests is unacceptable.
- Adding servers helps less each time, or not at all.
- The database CPU is saturated while the application servers sit idle.
- A handful of endpoints or queries account for most of the load, and nobody has measured which ones.
- Load tests exist but do not resemble real traffic, so they pass and production still fails.
- Performance fixes are made during incidents and quietly undone by the next release.
Measure the real load first
Performance work that starts from guesses tends to optimise the wrong thing. Caching is added in front of an endpoint that was never slow, while the real bottleneck, whether a lock, a chatty call pattern or an unbounded query, stays untouched.
We start by building a load profile from production data: which requests, in what mix, at what rate, with what data shapes. The load tests we build reproduce that profile, so what fails in the test is what would fail in production.
Fixes are made in order of impact, and each one is measured. Where a limit is structural, such as a design that cannot scale horizontally, we say so and design the change. Performance budgets and tests are then added to the pipeline so the gains are not lost in the next release.
Scope
Included
- Load profile from production traffic
- Realistic load and soak tests
- Bottleneck analysis across application, database and infrastructure
- Query and index optimisation
- Caching strategy with clear invalidation rules
- Concurrency, connection pool and timeout tuning
- Autoscaling and capacity planning
- Performance budgets and tests in the delivery pipeline
Not included
- Front-end and browser performance
- Rewriting the application in another language
- Buying more hardware as the only measure
- Ongoing performance monitoring as a service
How the work runs
- Week 1Profile the load. Production traffic, traces and database statistics are analysed to build a load profile and a baseline.
- Weeks 2 to 3Find the limits. Realistic load tests push the system until it breaks, and the first bottlenecks are identified with evidence.
- Week 3 onwardFix and measure again. Fixes are applied in order of impact. After each one, the same test is repeated and the result is recorded.
- Final weekProtect the gains. Performance budgets, tests and capacity guidance are handed over, so the next release does not undo the work.
What you receive
Tests, results and changes stay in your repositories.
Who this service is not for
- Front-end or mobile app speed problems. We work on the server side: APIs, data and infrastructure.
- Systems that are slow because of a single known bug. A focused fix is cheaper than a performance engagement.
- Teams expecting a guaranteed number before anything is measured. Targets are set once the baseline is known.
Frequently asked questions
Do you test against production?
Usually not. We test against a production-like environment with a realistic data set. Where a production test is the only option, it is planned with you and run at a safe time, with a way to stop it.
What tools do you use?
Open-source load testing tools and the tracing and metrics you already have, adding what is missing. The tests stay with you and run without us.
Can you guarantee a response time?
We set targets after measuring the baseline, and we report the results against them, including where a target needs a structural change to be met.
Will you need to change our architecture?
Sometimes. Most gains come from queries, caching, pooling and configuration. When a limit is structural, we show the evidence and design the change, often as a separate engagement.
How is this different from Observability and SRE?
This service finds and removes performance limits. Observability and SRE builds the monitoring, SLOs and incident practices that keep the system healthy over time.
Start with a short technical call
Thirty minutes. You describe when and where the system slows down, and we tell you how we would find the cause.