Check server load with Artillery

Tram Ho

Preface

If you have been a student of credit or a university cadaver in recent years, surely you will not be too far away from the scene of fighting over the web to register to study, to see the results of things. . While the water is boiling, you only get a brief message “500 Internal Server Error”, but turning to the next person, you can still see it is normal, so you tried F5 but the result no better.

And the reason is that there are too many people accessing the website at the same time, so the server cannot load, so some people can access, and some people cannot (the tools say due to human dignity ).

As a web developer, we will have to learn and offer solutions to avoid this situation. And the first step is to test it, certainly you can not send requests bằng cơm to test the load of the server, so the tool to support the load bearing of the server was born to make the life of the dev easy. more than part.

In this article, let’s take a look at one of our newly enlightened tools, which is Artillery .

content

Before going into learning about how to use Artillery, I also introduced it is always including 2 versions, 1 is Community Edition (free) and Pro (chargeable) . And in the scope of research, personal use, we will use the free version, and you who have conditions or follow the team can try the fee version (cost is about> $ 199 / month)

Setting

Because Artillery is written in Node.js, you need to have Node.js version 10.16.3 or higher installed, and the installation command is very simple.

Configuration and use

After the installation is completed, run some simple test commands

However, the above statement is just a very simple case, in fact, users often interact with the server in a script rather than just sending a request. And to run the test in a script, we need to learn some keywords to set up the configuration as follows:

  • target : server to test (usually base URL for HTTP application or hostname for WebSocket Server)
  • phases : test run time and frequency of requests sent during that time
    • in phases can declare several consecutive phases with duration and frequency of different requests
    • You can name each phase
    • Pauses can be used to create a pause phase, without performing any operations
    • rampTo : you can understand it like the for loop, for example, when declaring arrivalRate: 0 and rampTo: 10 , the artillery will be divided into consecutive phases with arrialRate 0, 1, 2, …, 10.
  • headers : declares the default HTTP header for all requests you send
  • environments : when you want to reuse the test for different environments (staging, production, …) with some minor changes to each environment, you can declare the environment as follows:
  • scenarios : test script declaration (declared like an object , REQUIRED contains flow attribute and may have some other properties)
    • flow: is an array, declaring the actions that virtual users will perform in those scenarios (can be request GET / POST to HTTP application)
    • name: describe in detail the operation of that scenario
    • weight: the weight of the scenarios, which is understood as the percentage that the scenario is selected to perform (for example, 3 scenarios A, B, C have a weight of 2,3,5, then A has 20% selected, B is 30% and C is 50%)

And the result we get is a .yml file with the same structure as below:

And to run the example.yml test above, we execute the command

The result will look like this:

Based on the above report, we can know the response status that the server returns on the total number of users who have sent requests to the server:

  • Of the 600 requests that were completed, 300 responses returned code 200 (OK) and 300 responses returned code 302 (Found). There are also other status codes, you can find out here .
  • Time to complete 1 request:
    • fastest: 52.1 milliseconds (0.052s)
    • longest: 11005.7 milliseconds (11s)
    • Average: 408.2 milliseconds (0.4s)
    • 95% of requests completed under 1727.4 milliseconds (1.7s)
    • 99% of requests completed under 3144 milliseconds (3.1s)

-> from the above statistics you can see that your server is running quite well with the number of requests as on the example.yml file, you can try increasing the arrivalRate to see how much the server’s load capacity is.

And when the server load limit is reached, you can learn more ways to increase the server load (for example, refactor code, scale by adding server hardware, etc.).

Epilogue

Within the scope of this article, I have just briefly introduced the tools to support load testing of the server only. As for the problem of how to increase the load on the server, I beg for alms in the following article, because honestly it depends on a lot of issues, so I cannot say it all in one article.

Thank you for following my article, if you find it useful, please support me upvote!

References

Share the news now

Source : Viblo