Once you build your application and you are ready to deploy it, is very important to know how it will behave once users will come and use it, otherwise it could fail miserably in real-world conditions.

To solve this problem here comes in place load testing.

Definition

Load testing is one type of performance testing, a subset of Non-functional testing.

Is there a need for Load Testing?

The purpose of this software testing is to determine the performance of the system in real-time load conditions. In simple words, it is used to ensure that the application performs satisfactorily and ideal doesn’t crash when too many users try to access or use it at the same time.

If you know that your traffic application is going to be low, then load testing can be a good practice, but if you are going to have a website with a lot of users/sessions, for example, E-commerce websites which invest heavily in advertising campaigns management, then load testing is a must.

In 2019 Costco website went down for more than 16 hours, costing the retailer nearly $11 million in lost for pre-Black Friday potential sales, approximately $11,035 a minute

In 2018 Amazon website went down during Prime Day for approximately 63 minutes which cost the company nearly $100 million.

Many sites suffer delayed response time when they encounter heavy traffic, thus the urge of load testing is obvious.

Best practices and goals:

While doing load tests you should consider the following aspects to assure the quality of your tests.

What are the goals of your test suite, what do you want to check? - do you want to see the response time for each transaction, do you want to see the performance of database components under different load, or to measure the network delay between the client and the server. This is important because you need to collect the right data for your tests and to run it the proper way. Run your tests early and often - the performance of your application is changing fast while you are in the development process, you can be one wrong implementation away from a bottleneck. Either because you crashed the application in an infinite loop without realizing it or because you haven’t caught an error which causes your application to return an error for all the requests Don’t change the environment - try to run your tests in an environment similar on which your application will be deployed Be realistic - try to make your tests to reflect the reality, there is no point in testing a scenario which will never happen; false data is worst than no data

How to do Load Testing?

Load testing can be done manually using code bundled in modules that are already built for this type of testing or using automated tools.

One of these tools is Loadmill and what it makes it different from other services is the usage of real web traffic to generate the load on the tested server, thus you can simulate real usage patterns from countless geographic locations and computers.

For example, let’s use one of this two demo applications

- [dummy ninja store](https://my-ninja-store.herokuapp.com/) - [loadmill test blog](https://loadmill-test-blog.herokuapp.com/)

If we want to see how our website behaves under certain payloads all we need to do is it to create a request in the Load Test Panel and supply the URL of our application.

We can add multiple requests and store variables across the test suite, thus we can mimic real user behavior including login credentials and tokens.

The next step is to hit that Run Test button and configure the number of the concurrent session and the test duration.

With this configuration, we’ll see how our application behaves when 50 concurrent sessions try to use the application in a 1-minute time frame.

As an output we can see the performance over time:

all requests had an average response time of 247 ms,

when we hit 49 concurrent sessions, 95% of the requests had a response time lower than 319 ms and 50% of the requests had a response time lower than 281 ms

At the same time, we can see the throughput in rps (requests per second) of our sessions.

If you think that the difference between concurrency and rps is not clear, then check this response on GitHub: how concurrency is related to rps

This data can help in identifying issues related to performance and bottlenecks.

We can collect even more data using this tool. For example, we can see how our application performs in different locations.

The software we tested is hosted in Europe, thus the response time for America is higher.

If you want to test your application all you need to do besides what you saw here is to verify your domain. You can simply do this by adding the domain on the platform and then load a .txt in your application.

How about doing manually?

Another way of doing Load Testing is to do it on your own.

LoadTest is a module that allows you to do this from your local setup.

To get started all you need to do is the following:

npm install -g loadtest

and to run a test

loadtest -c 50 -n 2000 https://my-ninja-store.herokuapp.com/

this will send 2000 requests with a concurrency of 50 to our application.

Furthermore, we can specify how many requests per second we want to send and we can use it to test application on localhost as well.

Now the data is not as comprehensive as using a tool and neither it’s relevance is not that good.

The value of the tests is strongly related to your local machine on which you run this code and you can go as further as your CPU allows you to. To improve the quality of these tests you can spin up a VPS(Virtual Private Server) on a cloud platform with a good performance, just to run your tests on it.