Stage 3From a few days
Monitor and improve
Measure, find what’s blocking, fix and monitor.
- A quantified assessment, backed by measurements
- Recommendations ranked by impact
- Hands-on delivery of the most useful ones, and follow-up
Case study · performance
SNCF Gares & Connexions: the station display API, 10 times faster.
When the load went up, the API that feeds the passenger information displays in major stations slowed down and returned errors. Measure, find the causes, fix, measure again: the average response time was divided by 10.
- Client
- SNCF Gares & Connexions
- Sector
- Transport · passenger information in major stations
- Need
- Make an API reliable under heavy load: response time and errors
- Stage
- Monitor and improve
- Engagement
- Two performance studies
- Technologies
- Web API, measurements under load, load testing in pre-production. Architecture details are not published.
÷10
Average response time, from 1.1 s to 0.1 s
0%
Errors under heavy load, down from 52%
+47%
More requests handled, under the same conditions
Figures measured under heavy load, before and after the fixes.
01Context
Passengers looking for their platform can’t wait.
In major stations, passenger information displays show departures, platforms and delays. Behind them, an API supplies that information, continuously.
The displays query it constantly, and load peaks come exactly when passengers need it most. That is when it fell behind.
Average time1.1 s
Errors52%
02The stakes
Under heavy load, more than half of the requests failed.
For a display that has to show the right platform at the right time, that is too much. It had to be fixed without changing anything the displays show.
Before · time
1.1 seconds per response, on average.
Every display waits for the API, and requests pile up as the load rises.
Before · errors
52% of requests failing.
Information that doesn’t arrive is a display that doesn’t update.
Constraint
No visible change.
Targeted fixes, without touching what passengers see on screen.
03Approach
Measure first, then fix.
Performance studies carried out end to end: every step is written down, with before and after figures, so the client’s team can check everything.
Measure
Under heavy load, in real conditions.
Understand
Measure each step of a response to find where the time goes.
Fix
Targeted fixes, checked one by one.
Prove
Measure again under the same conditions, then with a load test.
Deliverables
Two written performance studies, handed over to the client.
- Before and after measurements, under the same load conditions
- The figures for each fix
- Validation with a load test on the pre-production environment
04Results
Ten times faster. No more errors.
Average response time · under heavy load
Both bars move on the same time scale.
Error rate · under heavy load
Before52%
After0%
No more failed requests.
Requests handled · same conditions
+47%
The API absorbs more requests, faster.
API errors÷10
Write time4× faster
The studies are internal client documents: the architecture, the tools and the details of the fixes are not published here. Only the figures above are.
05For you
Your application slows down under load? The same work applies.
A product that slows down, returns errors at peak times or costs too much on AWS: the approach is the same. Measure, find what’s blocking, fix what matters, and prove it with figures.
For a product built by Elia Interactive or elsewhere.
Wooskill
The product of an online learning startup, built and extended block by block.
Your project