Case studies

Relampo in real projects: five performance cases

These five projects show how Relampo is used to validate capacity, find the component that limits a system and keep continuous watch over its APIs. Organization names and functional details of their platforms are omitted for confidentiality.

Case 1 · E-commerce

Root cause under sustained load

Challenge

An e-commerce platform needed to know how many concurrent users it could sustain before a campaign.

Approach

Stepped tests of 50, 100 and 300 concurrent users over the end-to-end purchase flows, with dynamic data correlation between steps; the 100-user test was sustained for 1 hour. Relampo results were cross-checked with server logs and infrastructure metrics from the same window.

Indicator	Result
Load levels	50, 100 (1 hour) and 300 concurrent users
Requests executed (100-user test, 1 hour)	221,328
P95 up to 99 users	180–358 ms, no errors
Degradation threshold	100 users: first error ~38 s after reaching them
300-user test	More than 50% failures: confirmed the system limit
Root cause	Concurrency contention in the database (locks between transactions)
Recommendation	Operate provisionally with ≤90 users until fixed and retested

Value

The first load error matched, to the second, the first lock recorded in the database. With that, the team knew where to act: it did not need more CPU or more nodes, but to fix concurrent data access. The analysis also separated primary failures from cascading ones, so nobody chased symptoms.

Case 2 · Air transport

Validating a change before turning it on

Challenge

An airline was about to deploy a security change on its website and needed to confirm it did not affect the load time of its main pages.

Approach

The same test ran twice, without and with the change, at 4 load levels (1, 10, 50 and 100 users). Relampo downloaded each page with all its resources (~46 requests per page) and reset cookies and cache on every iteration, simulating a new visitor. Results were cross-checked with logs and cloud service consumption.

Indicator	Result
Runs / requests	8 runs / 385,131 requests
Failures	4 (~0.001%), all isolated
P95 difference with and without the change (1–50 users)	Between −17.5% and +9.3%, no consistent pattern
Degradation point	100 users, with the service CPU at its limit
Risk detected	An inconsistency that would affect two pages when enabling the change

Value

The change could move forward with no evidence of consistent degradation between 1 and 50 users, the team learned the current limit of its service, and a risk was fixed before it reached production.

Case 3 · Enterprise services

Daily monitoring of critical APIs

Challenge

A company needed to detect performance degradations in its most critical APIs before they reached production, not when users reported them.

Approach

Relampo was integrated into its CI pipeline with five scripts covering the most business-critical APIs, running every day with a fixed, comparable load.

Automatic daily execution from the CI pipeline, with no manual intervention.
Slack alerts when an API drifts from its usual behavior: response times or errors.
Day-by-day history of each API, to see trends and compare against the baseline.

Indicator	Result
Time in operation	3 months (~90 runs)
Critical APIs covered	5 scripts
Frequency	Automatic daily run from CI
Regressions detected	In more than 15% of runs, tied to component changes in staging releases

Value

In three months of operation, more than 15% of daily runs detected performance regressions tied to component changes, in staging releases and before reaching production. The history shows when each degradation started and what changed that day.

Case 4 · Digital services

Mixed web and device load to find the component that does not scale

Challenge

A digital services platform needed to measure how its authentication responded to 5,000 concurrent users, combining web login with username and password and access from devices.

Approach

First, the team calibrated how many users each load generator sustains on two cloud CI platforms, and chose the one with the highest connection capacity for the web flow. Then the distributed test ran on 15 generators, with 10 minutes of sustained load.

Indicator	Result
Concurrent users	5,000 (3,750 device + 1,250 web)
Duration	14 minutes (10 of sustained load)
Requests / errors	648,925 / 0
Authentications completed	43,327
Authentication service	P95 of 0.69–0.80 s per request, flat for the 10 minutes
Web access	Progressive degradation in the password step (P95 of 13 s)

Value

Without a single error, the test showed the authentication service scaled and that the web part was the one starting to degrade. That made it possible to plan the next phase and focus the analysis on the limiting component.

Case 5 · Digital identity

From 10,000 to 15,000 concurrent users with no errors

Challenge

A digital identity platform needed to validate a target scenario of 10,000 concurrent users on its authentication service and learn the margin above that threshold.

Approach

Distributed tests of 10,000 and 15,000 users from two CI platforms (up to 28 generators). Relampo results were correlated with the infrastructure team's reverse proxy analysis.

Indicator	10,000 users	15,000 users
Errors	0	0
Typical request, P95	~150–245 ms	~720–860 ms
Full flow, P95	~5 s	12–14 s
Proxy: peak busy workers	37%	76%

Value

The target scenario was validated with client-side and server-side evidence: the proxy peaked at 37% busy workers. The 15,000-user test completed with no errors and identified the range (~2,200 req/s) where the platform starts to saturate.

Conclusion

In all five cases Relampo delivered the same thing: measurable evidence to decide. Target scenarios were validated, the component limiting each system was found before it affected users, and continuous monitoring of critical APIs was left in place, at minimal infrastructure cost.

Try it free Back to the landing page