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.
Every test starts from a question your management understands and ends with numbers that answer it.
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.
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.
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.
During the runs we follow CPU, memory, database connections and queues in Grafana, New Relic or your existing monitoring.
If you run in the cloud, we test whether scaling kicks in on time or only once the peak has passed.
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.
Bottlenecks ranked by impact with estimated effort, from missing indexes and caching to more server capacity, plus a fresh measurement after each change.
Allow at least four weeks before the critical date so there is time for improvements after the first run.
For instance: “8,000 registrations in 30 minutes, 95 % of pages under 2 seconds, error rate below 1 %.”
A test environment with realistic data volume, scripts, and coordination with host, CDN and payment provider.
Stepped load, peak load and soak testing, each with live server observation.
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.
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.
Which event is coming up and how many visitors do you expect? We will propose targets, scenarios and a timeline.
Your enquiry has arrived
Our reply reaches you within one working day. Outages that leave your staff unable to work are dealt with first.
We could not find that town. Try another spelling, or choose whichever provincial capital lies closest; as everything is handled remotely, you get the same service in all nine Austrian states.