Load test: Do you know when it fails?

The performance test measures the response time of a workflow under normal, continuous usage conditions. The load test pushes the system to its limits by simulating a massive influx of simultaneous users over a short period of time. One monitors performance, while the other determines system capacity.

Our Teams. Load testing is a service we provide—not a feature you simply launch from the platform: we prepare the test scenarios, calibrate the load levels, launch the campaign on the date agreed upon with you, and report the failure point along with the component that fails first.

That’s exactly how it works: our team handles the load testing. You don’t install or manage any load testing tools, nor do you provision any servers. We work with you to define the scope, carry out the testing during an agreed-upon time slot, and provide you with a report followed by a debriefing. Load testing vendors, on the other hand, sell you a tool that your teams must learn to use and operate.

In a production-representative environment; otherwise, the resulting figure is meaningless. In practice, several of our clients run tests directly in production, during an agreed-upon time slot and after notifying the hosting provider. Running tests on an under-resourced pre-production environment yields a conservative failure point, while running tests in production requires strict precautions regarding the data used.

We’ve already launched 5,000 simultaneous requests on the same test run. Once the number exceeds a few hundred, it’s often the infrastructure’s safeguards that respond first—with 429 errors or CDN errors—before the application itself. That’s precisely the threshold this test is designed to determine. The volume is therefore based on your historical peak and your target factor, and a gradual ramp-up is offered by default to determine the limit without sending everything at once.

This is a distinction that the report explicitly makes, and it changes the conclusion. Beyond a few hundred concurrent sessions, it is often the safeguards that kick in: a 429 rate-limiting code or a 503 error returned by the CDN. It isn’t your application that failed—it’s your safeguards that worked. The report lists the request, its status code, and the stage of the request flow, which makes it possible to distinguish between the two.

No, and we make that clear before providing a quote, rather than after the first run. A test run lasts one to two minutes and is not automatically restarted: we’re measuring the system’s ability to handle a peak load, not its endurance over time. If you need the system to maintain performance for several hours with a constant workload, you’ll need a query injection tool, not a replay of business processes.

In waves. At a given stage, all takes are completed in less than ten seconds, and each take takes one to two minutes, until payment is made. We observe, then move on to the next stage. A shoot takes up a one-hour time slot, which covers setup, the various stages, and wrap-up; a longer duration is accommodated within the budget.

Before any event that drives a surge in traffic: a sales promotion, a product launch, the start of ticket sales, or a media campaign. And after any major architectural change, because the weak link shifts.

The exact protocol for each test run, the number of successful executions per stage and its success rate, the median, minimum, maximum, and 90th percentile times, as well as each failed step along with the number of occurrences, a screenshot taken at the time of the failure, the return code, and the failed request. The raw logs are provided in the appendix.

It serves two purposes: sizing the infrastructure and fixing the component that fails first. The second one is often the most beneficial, because a single bottleneck can limit the performance of the entire chain.

Allow for a 14-day notice period and confirmation of the scope no later than 48 hours before the launch. This isn’t just red tape: a launch carried out without notifying the host, the on-call team, and the business unit will end badly.

That’s often the goal. We’re looking for the breaking point, not to confirm a safe figure. The test is stopped as soon as the observed behavior no longer makes sense, and the report describes what failed first, at what load level, and what to look for before the next test.