Service · Testing and QA

Load testing

Black Friday, a big newsletter, the morning a municipality opens sign-ups for a popular scheme: we tell you beforehand how your platform will cope. Software that feels fast with ten users can go completely silent at a thousand rather than merely slowing down.

Send an enquiry See the scope

The limit

breaking point located

Weakest link

what fails first

Traffic model

based on real users

Rerun

after every optimisation

What the service covers

We simulate what your users really do, rather than firing an arbitrary count of parallel connections at the server.

Talk it through with us

Traffic model

The mix of activities on your site: browsing products, using search, filling the basket, paying by MobilePay or card.

Scripts

Written in k6, JMeter or Gatling to imitate human pacing, think times included.

Ramp-up

Traffic climbs in stages while we watch for the point where latency starts rising.

Weakest link

CPU, RAM, storage, the database or a third-party API: we establish which one caps performance.

Recovery

What happens once the limit is passed, and whether the platform heals itself when traffic drops.

Recommendations

Configuration changes, code rewrites and scaling steps, ordered by value.

How we deliver it

Scripting takes a few days. Each run is short and gets repeated after every improvement. Traffic is generated from cloud machines, so you install nothing.

Targets

Required throughput and acceptable response times. Without numbers, a test has no pass mark.

Set-up

An isolated environment, the scripts and a production-sized data set.

Runs

Stepwise increases in load, with metrics captured at every level.

Analysis

Findings on each bottleneck plus a remediation roadmap in order of priority.

Third-party services tend to buckle before your platform does. Payment gateways, carrier APIs and email providers all enforce rate limits. A test must either include them or swap them for clearly labelled stubs, and the report has to reflect which option was chosen.

Common questions

Please avoid it: real shoppers could be locked out and your analytics polluted. A cloned environment is the proper target. Where none exists, we run throttled tests overnight with your sign-off.

Peak demand multiplied by two or three, never the daily mean. Visitors arrive in spikes triggered by campaigns, ads or press coverage, so averages hide the real risk.

Start with caching and faster database queries, which are cheap and frequently multiply capacity. Adding cloud resources is step two; redesigning the architecture is the final resort.

Usually, yes. A sudden surge can look like a DDoS attack to hosting providers and CDNs. We help you notify them and pick a time slot.

Related services

View the whole area

Service Functional testing Every user journey checked before release Service Test automation Automated tests for the checks you repeat Service Usability testing Real users reveal where the interface trips them up Service Penetration testing Vulnerabilities found before anyone else finds them

Let us put your system under pressure

Share your expected visitor numbers and your deadline. We simulate the surge and pinpoint where things start to go wrong.

Email
office@apply.dk

Coverage
All of Denmark, delivered remotely

I agree that Apply may handle my details as set out in the privacy policy