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.
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.
A graph is not the deliverable. A reasoned answer to “will we stay online that evening?” is.
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.
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.
A slow ramp, an abrupt surge, a soak lasting several hours and a stress run that adds load until something fails.
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.
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.
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.
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.
We schedule backwards from launch day. Four weeks fits a first run, repairs and a confirming run without rushing.
For instance: “15,000 shoppers from 21:00 to 21:30, 95% of pages in under two seconds, failures under 1%.”
A staging copy close to production, realistic data volume, scripted journeys, and a heads-up to the host, CDN and payment provider.
Ramp first, then surge and soak, each followed by a quick look at what we learned.
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.
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.
What date matters and what traffic do you expect then? We will propose success criteria and a schedule leading up to it.
Enquiry received
An engineer will write back no later than the following working day. Faults that leave your staff unable to work are always looked at first.
No town by that name here. Check the letters, or settle for the nearest larger place. Our engineers work only over the internet, so Kočevje and Koper get precisely the same treatment.