Usage scenarios
We reproduce what people actually do: browse categories, search, add to basket, sign up, pay by card or Bizum, download a receipt. The mix between actions comes from Google Analytics, Matomo or the logs rather than a rough guess.
Most systems have one day a year that decides everything. For a PrestaShop store it is Black Friday or the first day of the sales; for a town council's online services portal, the morning applications open for grants or summer camp places; for an online academy, enrolment week. The rest of the year the server has capacity to spare, so nobody suspects a thing. Load testing recreates that day ahead of time on a copy of the system and tells you how many users it copes with, which component gives way first and what it costs to gain headroom. We generate the traffic from the cloud and work remotely, with no agents installed on your servers.
This is not about firing millions of requests to see what happens. Each test answers a specific business question and is designed around your traffic data and server logs.
We reproduce what people actually do: browse categories, search, add to basket, sign up, pay by card or Bizum, download a receipt. The mix between actions comes from Google Analytics, Matomo or the logs rather than a rough guess.
We add users in stages and note the point where response time goes from fine to irritating, and the point where errors begin. Those two numbers are what management wants to hear.
We push the system past its limit and simulate the rush in the first minutes after a newsletter or a push notification. How it fails matters as much as when: with a polite holding page or with a blank screen.
Sustained traffic over several hours to expose what only surfaces with time: memory that is never released, growing queues, piling-up sessions, disks filling with logs.
We look at the slowest queries, missing indexes and pages rebuilt again and again for no reason. In PrestaShop and WooCommerce, filtered category listings and the search function are usually the first suspects.
The payment gateway, the carrier's shipping rate API or the transactional email service all have their own limits. We either get each provider's permission or swap them for simulators during the test, and the report says which.
Results with readable charts, bottlenecks in priority order and the expected effect of each change. A bigger server only appears in the plan when it genuinely beats fixing the code or configuration.
Preparing scenarios generally takes a few working days, and each test round lasts a few hours. It pays to start several weeks before the critical date so there is time to apply improvements.
For example: «2,000 concurrent users with responses under 2 seconds on product pages and basket». Without a numeric target there is nothing to measure against.
A copy of the system with a data volume close to the real one, and an agreed window with your hosting or cloud provider.
Stepped runs while your team or ours watches the server monitoring live.
The most cost-effective changes go in, then a fresh round shows how much was really gained.
A bigger server will not fix a badly written query. Small firms often double their hosting bill ahead of a campaign and the site goes down anyway, because the real culprit was an uncached listing firing two hundred queries per visit. Measuring first and spending afterwards almost always works out cheaper.
Probably not, which is exactly why you need to know. Shared hosting cannot be tested without the provider's consent because other customers are affected. In that case we build a temporary copy on an equivalent VPS or cloud instance in a data centre in Spain or the EU and remove it afterwards.
Access to analytics or logs to design the scenarios, a copy of the system or permission to build one, test accounts and a technical contact during the runs. If the shop takes payments through Redsys, we also need access to the POS test environment.
Only as an exception, overnight, with capped traffic and a signed-off window. Normally we use a copy so that real customers are unaffected and your sales statistics stay clean.
Always. Lots of requests from a handful of addresses look very much like an attack, and the protection at Arsys, IONOS, OVHcloud or Cloudflare may cut the test off halfway. We help you draft the notice and fix the date.
Tell us which date worries you and how many people you expect. We will suggest scenarios and a timeline that leaves room to spare.
Your request is with us
Expect an answer within one working day. A reported fault that has halted your team is handled first.
No match found. Try another spelling, or go with the closest provincial capital: every job is done remotely, so the location makes no difference to what we deliver anywhere in Spain.