Finding an eCommerce platform's breaking point in three weeks

Three continents, one platform, one open question

An international eCommerce platform serving markets in Europe, Africa and South America planned an architectural change. Multiple vendors had built parts of the application and infrastructure, and none of them could say what the change would do to performance under load.

This engagement built on a partnership of over seven years and more than 40 projects together.

How many users before it breaks?

The client needed answers before onboarding more customers: how many concurrent users can the platform take, where does it break, and what does that mean for scaling the Azure environment up or down without overspending?

The timeline left no slack. Scripting, workload modelling, multiple test scenarios, execution, monitoring and analysis, all inside three weeks.

A workload model built from real traffic

One spriteCloud performance engineer ran the project, with a test manager presenting strategy and results to stakeholders. The first step was building a workload model that matched reality: we analysed production traffic in Google Analytics on peak days, per country organisation, and recreated that pattern in OctoPerf. New Relic, already in place at the client, handled monitoring.

Five scenarios, from baseline to breaking point

Baseline at 100 percent of peak load to verify the new architecture. Then 150 percent, validated against pre-agreed KPIs. The same again with back-office load running in parallel, to measure degradation. Then stress tests, first per country and then combined, pushing concurrent users up until the platform broke. Front-end page load behaviour was analysed throughout.

The bottleneck was garbage collection

The stress test found the breaking point: throughput saturated and the application stopped processing additional requests. The cause sat in CPU utilisation, and inside that, in garbage collection. 35 percent of CPU time went to garbage collection and only 65 percent to actual application work.

We recommended a G1 GC configuration change to claw that capacity back, flagged the slowest queries and Java methods as bottlenecks under peak load, and added front-end fixes such as image compression and resizing.

A concrete ceiling, then twice the headroom

• Breaking point identified and tied to a fixable cause, not guesswork.
• 2x concurrent users: the client expanded the platform to serve twice the load.
• 3 weeks from first script to final stakeholder walkthrough.
• Continuous performance monitoring: the test scripts were converted into an on-demand setup that compares each deployment against the benchmark.

Performance regressions now surface in the development pipeline, not on a peak sales day.