Service · Software testing and QA

Load and stress testing

Picture a private organiser handling online registration for a popular fun run in Carinthia. Last year 6,000 places went in half an hour, and for the first few minutes the server returned nothing but errors. This year there are 8,000 places, with card and eps payment on top. Whether that will hold can be measured in advance. A load test sends a defined number of simulated entrants through registration, records response times and errors and shows which part gives out first: database, application, payment provider or email delivery. A stress test goes further, finding out how the system behaves beyond its ceiling and whether it recovers by itself afterwards. We generate the traffic from the cloud, agree timing with your hosting company and work purely remotely.

95th percentile
not flattering averages
k6, JMeter, Gatling
chosen to suit the application
Real patterns
from logs and analytics
Recovery
checked after overload

Everything this covers

Every test starts from a question your management understands and ends with numbers that answer it.

Settle the details with an engineer

Load profile

How many visitors arrive over what period, what they do and how long they stay. We derive this from logs, Google Analytics or Matomo and scale it up to the expected peak.

Test scripts

Realistic journeys in k6, JMeter or Gatling covering sign-up, search, basket and sandbox payment, with varied data rather than the same entry a thousand times.

Meaningful metrics

Response time at the 95th percentile, error rate and throughput per second. An average of one second is little comfort if every twentieth visitor waits ten.

Watching the servers

During the runs we follow CPU, memory, database connections and queues in Grafana, New Relic or your existing monitoring.

Checking auto-scaling

If you run in the cloud, we test whether scaling kicks in on time or only once the peak has passed.

Queueing and protection

For extreme spikes we assess whether a virtual waiting room makes sense, so visitors are let in in an orderly way instead of meeting an error page.

Actions that pay off

Bottlenecks ranked by impact with estimated effort, from missing indexes and caching to more server capacity, plus a fresh measurement after each change.

Our working method

Allow at least four weeks before the critical date so there is time for improvements after the first run.

01

Setting targets

For instance: “8,000 registrations in 30 minutes, 95 % of pages under 2 seconds, error rate below 1 %.”

02

Preparation

A test environment with realistic data volume, scripts, and coordination with host, CDN and payment provider.

03

Test runs

Stepped load, peak load and soak testing, each with live server observation.

04

Improve and re-run

Your team or ours implements the most effective measures, then a second run shows the difference.

Test the services you do not run yourself as well. Often your own application copes, but the email service throttles after a thousand messages an hour or the payment gateway has a rate limit nobody knew about. Ask your providers about their limits beforehand, or let us expose them during the test.

Frequently asked questions

Mostly k6, as scripts version well and slot neatly into CI pipelines. For complex protocols or existing suites we use JMeter, and Gatling for very high volumes.

Ninety-five out of a hundred requests are faster than this value. It reflects the experience of your worst-served visitors, which makes it more telling than an average.

Yes, for the load generators and possibly for a scaled-up test environment. For most tests these costs stay in the low hundreds of euros, and we estimate them in advance.

Only if the peak sits well above what can be scaled economically, as with ticket sales or capped registrations. For ordinary sale days, optimisation is usually the better investment.

Before every major event and after significant technical changes. Built into the CI pipeline, a small load test can also run with each release and reveal gradual slowdowns.

Let us measure how resilient your system is

Which event is coming up and how many visitors do you expect? We will propose targets, scenarios and a timeline.

Availability
Monday to Friday, 8:00-17:00 Austrian time (CET/CEST), reply within one working day
Meetings
By video on Microsoft Teams or Google Meet

We only use cookies that are technically required: to run the website and to remember the location you picked. There are no advertising or tracking cookies. Details are in the privacy notice.