Performance engineering
Measure before concluding, and know what the number means.
01 — The problem
You’re told the application is “slow.” You have a number — an average response time — that matches nobody’s experience. Load tests, when they exist, run on an environment that looks nothing like production, with a dataset ten times smaller. Results can’t be compared from one campaign to the next.
02 — What we do
- 01
Define what must be met, and for whom
Targets expressed as percentiles on real user journeys, not as an overall average. The average hides precisely the users who are suffering.
- 02
Build a representative test environment
Data volumes, configuration, external dependencies. Without this, the results are not transferable.
- 03
Run the right types of tests
Load, stress, endurance, capacity. Each one answers a different question; confusing them leads to wrong conclusions.
- 04
Analyze down to the cause
Application profiling, SQL execution plans, contention, saturation. A report that stops at the symptom is useless.
- 05
Make measurement last
A campaign that can be rerun in CI, results comparable over time, an alert threshold on regression.
04 — What you receive
Named deliverables, not promises. You know what you will receive before we start.
Quantified, justified performance targets
Repeatable load scenarios
Analysis report with identified causes
Recommendations prioritized by estimated gain
05 — Technical ecosystem
Tools do not make quality. We master them so that we can choose the right one, not to use them as a selling point.
- k6
- Gatling
- JMeter
- Grafana
- Prometheus
- OpenTelemetry