Услуга · Тестирование и QA

Load testing

We find out in advance what will happen on sale day or after a mass mailing. A system that is sprightly with ten visitors often does not merely slow at a thousand but stops responding altogether.

The limit
we find the breaking point
The bottleneck
what gives way first
The profile
we reproduce real people
Repeat
after each optimisation

What the work includes

The test is built on a real behaviour profile rather than an abstract number of concurrent connections.

Discuss the scope

The profile

What visitors do and in what proportion: browse the catalogue, search, place an order.

Scenarios

The scripts reproduce real behaviour including the natural pauses between actions.

Ramping up

We increase the load gradually and record the moment the response time starts to rise.

The bottleneck

We identify what gives way first: the processor, memory, disks, the database or an external service.

Past the limit

How the system behaves past the failure point and whether it can recover on its own.

Recommendations

What to configure, what to rewrite, what to scale up and in what order to do it.

How it goes

Preparing the scenarios takes a few days; the runs themselves are quick and repeat after every change.

01

The goal

What load has to be handled and at what response time. Without concrete numbers there is nothing to test against.

02

Preparation

A separate environment, the scripts and a data volume comparable to production.

03

Test runs

We raise the load in steps and take measurements at each level.

04

Analysis

A report with the bottlenecks found and the order in which to address them.

External services usually give way before your own system does. A payment gateway, a delivery service or a mail provider has its own request limits. In a load test they either have to be included or honestly replaced with stubs, and that has to be reflected in the conclusions.

Questions and answers

Strongly inadvisable: the test can make it unavailable to real visitors and distort the analytics. Better to bring up a copy on a separate environment. If there is no copy we work at night, with limits and by agreement.

For the peak with a two- or threefold margin rather than the average. Average traffic tells you almost nothing: load arrives in spikes after a mailing, an advert or a mention in the news.

The order is usually this: caching and query optimisation first, as they are cheapest and often give a multiple improvement. Adding capacity comes second, rearchitecting last.

We will test the system to its limits

Tell us the expected load and the deadlines. We will model the traffic and show where the problems begin.