You are launching an online shop. Small, big. You want shoppers to move smoothly through the stages of the sales funnel without getting frustrated with the wait time for your app to load. Or maybe you want to increase the capacity of the platform you already manage because Christmas or Black Week is coming? Is your service getting “clogged”?

What should you pay attention to? Are performance tests necessary? Or maybe stress tests?

More and more often companies entering the market, as well as those existing for nearly 30 years, ask us to perform performance tests of their services. Most often, they do so just before a hot period for them (e.g. a product launch or a holiday season). Significantly, they know that there is a risk with the use of the online channel that a potential buyer may become discouraged with their platform due to too long time of waiting for application components to load.

Do you know how many and what for?

At the outset, it is important to estimate the number of potential visitors. On this basis we are able to show how the website will behave under the load of users:

  • how quickly it will respond to user actions,
  • how fast will particular elements of the application load,
  • under what load the number of users will stop responding.

But the quantities and numbers are provided by the client, as only he knows his business strategy and is able to estimate it.

Bottlenecks

The points where the service may get stuck are important. Such bottlenecks are pages that may be connected to databases (e.g. generating images, prices) or simply may have suboptimal code or structure.

The bottleneck may also be the infrastructure on which such a platform is set up, but thanks to our service the client will find out how much it should be able to scale it and what costs can be expected.

We can and usually do perform 2 types of tests.

Load Test, that is simulating a large number of users in a long time – to check the service behaviour in the time of longer increased traffic (e.g. around Christmas or in the case of ticketing systems – around sport events).

Stress Test – simulating a large number of users in a short time, which can show if and when the infrastructure will be overloaded and if the system operation during the test is correct internally and does not cause other disturbances than longer waiting times.

A specific type of Stress Tests are dedicated DDoS (distributed denial of service) attacks, which we perform to check how the infrastructure will function with millions of requests to the service with a very, very short time.

What do you want to test?

At this point we should answer the question what is the purpose of the tests.

  • Do we want to check the optimisation of the website code?
  • The infrastructure on which it is based?
  • Response times?
  • The maximum possible traffic that allows to use the service?
  • To check how long the service will stabilise after a very heavy load?

If you have gone through the above points, now WE step in and start by meeting you and listening to what you care about. Are server response times important to you in your report? Or maybe checking if all images load?

After such a meeting, during which we discuss 3-6 most common purchase scenarios, we start to act and, being in constant contact, we perform the requested tests.

Usually the execution of one test scenario together with the test report takes about 3-4 days, depending on its complexity, length and technical details.

Our test report may include:

  • query statistics,
  • response time statistics,
  • failure statistics,
  • number of users,
  • detailed exception statistics.

Apart from a detailed report in a table, it will also have graphical charts which will show you at what point there are correlations between e.g. the number of users and server response times.

And most importantly – the requested report is discussed with the client during a meeting, and if he has a service subcontractor – with him as well. It is important that the results of the report are understood by the Customer not only from the technical side but also from the business side.