Service · Software testing and QA

Load and stress testing

Say you sell prams, car seats and other baby gear online from Celje, and Black Friday is approaching. Twelve months ago an influencer posted a pram link at 9 pm and the shop went down for twenty minutes. Baskets emptied; complaints arrived overnight. This time there will also be a television spot and a larger social campaign. You do not have to hope the platform holds; you can find out. A load test drives a chosen number of simulated shoppers through the site. They browse, search, fill baskets and head to the payment page while we log timings and failures and pinpoint the first component to give way. Is it the database, the app server, the round trip to the payment gateway, or the job pushing stock levels to marketplaces? The output is a set of hard numbers rather than a feeling that the shop is quick or sluggish, and it is written so the board can read it.

p95 and p99
averages hide the slow tail
k6, JMeter, Gatling
picked per project
Real behaviour
modelled on logs and analytics
Second run
after every change made

Scope of the service

A graph is not the deliverable. A reasoned answer to “will we stay online that evening?” is.

Check the scope with an engineer

Modelling traffic

Server logs, GA4 or Matomo tell us your peak minute and what shoppers do in it. We then multiply that pattern up to the volume the campaign should bring.

User journeys

Browse, search, filter, add to basket, sign in, pay via a sandbox at a provider like Stripe or Bankart. Every simulated shopper picks different items and data instead of hammering one URL.

Test types

A slow ramp, an abrupt surge, a soak lasting several hours and a stress run that adds load until something fails.

Meaningful metrics

Timings at the 95th and 99th percentiles, the share of failed requests, and throughput. One second on average sounds fine; it is not fine if every twentieth shopper waits ten.

Tracing the weak link

While load is applied we follow CPU, RAM, database connections, slow SQL and the length of job queues, either in the monitoring you already use or on dashboards we set up just for the test.

Outside services

Payment gateway, courier API, mail and SMS gateways, marketplace stock feeds. Your own stack may cope while their per-minute quotas become the real ceiling.

Fixes by impact

Absent indexes, caching, CDN tuning, more server capacity, a queue page if it comes to that. Each proposal is costed in effort and re-measured once applied.

How the work runs

We schedule backwards from launch day. Four weeks fits a first run, repairs and a confirming run without rushing.

01

Success criteria

For instance: “15,000 shoppers from 21:00 to 21:30, 95% of pages in under two seconds, failures under 1%.”

02

Setting up

A staging copy close to production, realistic data volume, scripted journeys, and a heads-up to the host, CDN and payment provider.

03

Runs

Ramp first, then surge and soak, each followed by a quick look at what we learned.

04

Repair and repeat

The biggest wins are applied, identical journeys run again, and the two sets of results are set out together.

Let your host and security provider know in advance. A flood of requests in a few minutes is exactly what DDoS shields and web application firewalls are built to stop. The run may be throttled and our load generators blocklisted. Sharing the slot and our source IPs beforehand protects the results and spares everyone false alarms.

Your questions answered

Preferably not; we use a staging copy that matches production. If production is the only option, we agree an off-peak slot and notify your providers first.

Not exactly. People pause, read and hesitate, so pauses between pages are copied from your analytics data. The figure that matters is requests and transactions per second reaching the server, not head count.

Load generators in the cloud, plus a temporarily larger staging environment if required, add a small infrastructure bill. It appears as its own line in the plan before anything starts.

Four weeks ahead at least. An initial run almost always reveals several weak points, and repairing them and checking again needs time. Testing in the last week merely brings bad news forward.

Yes. Scripts are usually written in k6 and committed to your repository. A light version can sit in CI so any major change shows straight away whether speed has dropped.

Put numbers on your peak day

What date matters and what traffic do you expect then? We will propose success criteria and a schedule leading up to it.

When we work
Weekdays 9:00-17:00 CET, answers the same or next working day
Calls
Video meetings, Teams and Meet both welcome

We set essential cookies only: the ones that keep the site running and recall which town you chose. Nothing for ads and nothing that follows you around the web. Details are in our privacy and data protection notice.