Visitor profile
What share of visitors browse categories, how many use search, how many reach checkout and pay with BLIK or through PayU. The ratios come from your own statistics.
A test is only meaningful if it resembles a real trading day. That is why we start from Google Analytics and server logs rather than a round number of connections.
What share of visitors browse categories, how many use search, how many reach checkout and pay with BLIK or through PayU. The ratios come from your own statistics.
Scenarios in k6, JMeter or Gatling that imitate humans: reading pauses, logging in, different products in the basket.
Users are added in batches while we note the count at which response time passes 2 seconds and the one where 5xx errors show up.
Several hours of steady load. Memory leaks and overflowing queues surface only after a while, never in the first few minutes.
We watch CPU, memory, disk, the database and third-party services. Very often the culprit is a single unindexed SQL query or a category page with no caching.
Does the system recover by itself once traffic drops, or does someone need to restart it by hand? That is the gap between a minute and an hour of downtime.
What to change in code, configuration or infrastructure, in which order, and what gain to expect from each step.
Preparing scripts takes a few working days. The runs themselves are short and are repeated after each fix. Traffic is generated from the cloud, so nothing gets installed on your servers.
How many simultaneous people the system must serve, and within what response time. Without a concrete figure there is nothing to measure against.
A separate copy of the system with a database close to production in size. On an empty database everything is fast and the result means nothing.
Load goes up in steps and each level is measured, alongside monitoring of the servers on your side.
A report on bottlenecks, fixes ranked by value for money, and a fresh run once the most important ones are in place.
External services usually give up before your own server does. The payment gateway, a courier API, an integrator such as BaseLinker or the email delivery service all have their own request limits. In the test they must either be included with the provider's agreement or honestly replaced by stubs, and the conclusions have to say so plainly.
We advise against it. The test can take the site down for real customers and distort your sales figures. A separate copy of the environment is best. If none exists, we run at night, with capped traffic, in a window agreed in writing.
The peak rather than the average, with a margin of two or three times on top. Monthly averages tell you very little: customers arrive in waves after a mailing, a TV advert or a mention in the press.
Usually caching and database query tuning come first, because they are cheapest and often bring a clear gain. A bigger cloud server is the second step, architectural changes only the third.
In most cases, yes. A sudden flood of requests from a handful of addresses looks like a DDoS attack to hosts and CDNs, and may be blocked halfway through the run. We help you draft the notice and pick a date.
Tell us what traffic you expect and when. We will simulate the load and show where trouble starts.
Your enquiry has reached us
You will hear back within one working day, and if you have reported an outage that is holding up work, it goes to the front of the queue.
No match for that name. Try a different spelling or pick a bigger town nearby - all our support is delivered online, so your choice has no effect on the service.