Service · Software testing and QA

Load and stress testing

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.

Breaking point
how many users it really handles
Weak link
identified with data, not hunches
Scenarios
built from your own analytics
Re-measurement
after every improvement

What falls within the scope of this service

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.

Pin down the details with one of our engineers

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.

Stepped load

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.

Stress and sudden spikes

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.

Soak testing

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.

Database and caching

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.

Third-party services

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.

Report and improvement plan

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.

How the engagement unfolds, one stage at a time

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.

01

Question and target

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.

02

Environment set-up

A copy of the system with a data volume close to the real one, and an agreed window with your hosting or cloud provider.

03

Load rounds

Stepped runs while your team or ours watches the server monitoring live.

04

Improve and repeat

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.

Common questions

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.

Let us find out how much traffic your system can take

Tell us which date worries you and how many people you expect. We will suggest scenarios and a timeline that leaves room to spare.

Hours
Monday to Friday, 9:00-18:00 Spanish time (CET), answers within a working day
Meetings
Video calls via Google Meet or Teams

This site only stores the cookies it needs to work and to remember your chosen city. No advertising or tracking cookies are set. See our privacy policy for the details.