How I Started Load Testing on a High-Load Service (P.S. It's Easy as ABC)

About a year ago, I started working for VK on the citymobil project, which is one of the largest taxi services in the post-Soviet space.

I joined the platform team that was engaged in solving global tasks for the entire project and began to establish quality assurance processes from scratch since the team was just emerging.

It should be noted that the testers were in other teams; in total about 40-50 people were possible on the project.

Let's get back to the topic. In the process of work, I noticed something that struck me. It turns out that within the framework of the project, the testers did not do load tests.

I was surprised that such a large project, which is associated with a large turnover of money, does not ensure the quality of the load on the service and does not properly check the throughput. I started changing processes, and I started with my team.

I was in the backend team. I started doing the load on the backend. Today I want to talk about the HTTP protocol load testing.

Let's first understand that load testing is a.k.a. performance testing simulating the work of users on any resource. The goal is to check performance (response time) on different resource loads.

This is research and analytical work.

During load testing, you can get answers to the following questions:

What will be the behavior of the system in real conditions under loads of different levels and duration?
What will be the response time to user requests, as well as the time of stable behavior with an increase in the number of users?
Does the system meet the performance requirements?
What margin of reliability and performance does the system have?
Which part of the system causes failures in its operation?

And now let's move on to the most interesting, to the beginning of the service load.

In fact, there are lots of load testing tools for HTTP protocol as an example today I will analyze suchVegeta - an open-source application written in GoLang for HTTP load testing. Vegeta is available for all platforms. The main concept in Vegeta is the so-called target. Target is what will be tested, in Vegeta terminology - what will be attacked.

Let's skip the installation step. And let's get down to the fun. I'm starting to test the performance of the service.

1) For example, I need to attack the Hello-world service, prescribe it via echo,

echo "GET http://hello-world.com/api/test"

2) Then, I specify in what interval the attack on the specified service will take place and the number of requests. I do it through

-vegeta attack duration=60s —rate=84/s

3) Output the result to the command line via

vegeta report

It turns out like this:

echo "GET http://hello-world.com/api/test /" | vegeta attack duration=60s -rate=84/s | vegeta report

Launch!

I get such a result:

What about the graphs?

Run this command.

vegeta plot results.bin > results-plot.html

You will get a graph:

I also recommend that you set up a graphana for your service, so you can compare the load from the tool and the performance of your service.

Thank you for your time, that is all. In the next part, I will tell you how to perform load testing on gRPC.