Load testing of Web-systems. How to prepare for it
If you all know about load testing and how to prepare for it correctly, then you will not be interested in the article. The article is designed for those who want to understand how to build the "right" profiles for testing and what you need to pay attention to when preparing the script. It will be a web-based system with a web interface.
I have been working in the field of testing for more than 10 years, in one way or another I come across stress testing. I read various articles on this type of testing, attended conferences, tried to learn something new and innovative in this area. In most of the information you receive, you will find instructions for testing microservices, databases, and other subsystems separately. Moreover, if the subsystems are checked and configured properly, then the Web system as a whole is not given due attention.
What is now Web-system is a set of microservices, subsystems, databases, etc., which can be located on different servers, on different continents. But they all somehow interact with the Web interface (as I wrote above, I consider only the current version).
Many utilities to perform load testing have the ability to record traffic. Almost all utilities record received requests sequentially in a single session. That is, request by request and do not care about how these requests are executed in browsers.
')
Take a few of the most popular browsers (Google Chrome, Mozilla FireFox, Internet Explorer) and try to open any site. As practice has shown with browsers, some have a setting for how many connections they can open in parallel, some regulate this number themselves. In addition, the number of compounds may vary depending on the type of compound used.
Internet Explorer:
Google Chrome:
For example, I saw how a different number of parallel connections were created for the same https resource. So Google Chrome created 6 connections and processed all requests within this number, but Internet Explorer could create up to 20 - 30 parallel connections.
We see that browsers access the Web system in several threads, they can load content in parallel. But a number of utilities execute only one thread for one user.
That is, it is actually incorrect to say that one thread in the utility for testing performance will always correspond to the work of one real user.
The load may be several times higher than the utility used will generate.
Referring to the settings of Web-servers, we will see that they determine mainly the number of working processes and the number of open connections. The operating system with which the load is made may have its own limitations on the number of open connections, which will affect the load profile and will not be related to the operation of the Web system.
In other words, each virtual user can support multiple parallel connections. And even with one user, you can load the system so that it can not work. If you use a utility that performs only one stream (supports only one connection) for one user, then you should understand that this stream is not a real user.
You need to pay attention to the fact that Web-systems can use third-party resources. This may be analytics, counters, provided fonts, styles, javascript. Depending on your needs, you need to determine for yourself exactly what resources you need to test. In the third-party resources, any information can be initialized, which you can later use on your system. Thus, by excluding third-party resources, you will not be able to simulate completely received content for the user. The necessary list of requests can only be determined by long analysis and a deep understanding of the system under test.
The picture shows a situation where a request is made to a resource, we will consider it testable, which makes a request for something different from it. This is where we need to decide whether we need this resource in our scenario or it is not related to the Web system and we can simply exclude it.
It is necessary to group requests for actions performed. So you can create separate groups to open the main page, to enter the system, to follow a link, etc. This is all you need mainly to establish the necessary delays between groups of actions. We consider one virtual user as a user who really works with the system. Naturally, if there are 100, 200, 1000 and more real users, each of them will spend a different amount of time on a particular page. Consequently, traffic must be uneven from virtual users. Therefore, it is necessary to establish delays between action groups. And the more real they are, the more real test results you will receive.
We can ignore the number of concurrent connections, third-party resources, groupings and delays. But as a result, we can get test results where it is clear that the system works with 200 virtual users (streams), but in practice you get only 10 real ones. Or get directly the opposite results, when according to the charts we see only 200 users can work with the system, but taking into account the different times of using the pages, the number of connections used and the exclusion of third-party resources, we can get 500 really working.
I believe that a clear understanding of the number of connections made, the correct use of the necessary set of resources and the delay between the groups of actions will help you to get more accurate load testing results that you will perform in yourself.
Of course, this is not a complete list of points from which preparation should begin. There are many more different aspects that somehow affect performance testing. Some of them can directly affect the agent that performs the load and may not be in any way connected with the tested Web system.
Update: we continue training in the article
Update2: we finish the preparation in the article
I have been working in the field of testing for more than 10 years, in one way or another I come across stress testing. I read various articles on this type of testing, attended conferences, tried to learn something new and innovative in this area. In most of the information you receive, you will find instructions for testing microservices, databases, and other subsystems separately. Moreover, if the subsystems are checked and configured properly, then the Web system as a whole is not given due attention.
What is now Web-system is a set of microservices, subsystems, databases, etc., which can be located on different servers, on different continents. But they all somehow interact with the Web interface (as I wrote above, I consider only the current version).
Many utilities to perform load testing have the ability to record traffic. Almost all utilities record received requests sequentially in a single session. That is, request by request and do not care about how these requests are executed in browsers.
')
Number of connections and execution sequence
Take a few of the most popular browsers (Google Chrome, Mozilla FireFox, Internet Explorer) and try to open any site. As practice has shown with browsers, some have a setting for how many connections they can open in parallel, some regulate this number themselves. In addition, the number of compounds may vary depending on the type of compound used.
Internet Explorer:
Google Chrome:
For example, I saw how a different number of parallel connections were created for the same https resource. So Google Chrome created 6 connections and processed all requests within this number, but Internet Explorer could create up to 20 - 30 parallel connections.
We see that browsers access the Web system in several threads, they can load content in parallel. But a number of utilities execute only one thread for one user.
That is, it is actually incorrect to say that one thread in the utility for testing performance will always correspond to the work of one real user.
The load may be several times higher than the utility used will generate.
Referring to the settings of Web-servers, we will see that they determine mainly the number of working processes and the number of open connections. The operating system with which the load is made may have its own limitations on the number of open connections, which will affect the load profile and will not be related to the operation of the Web system.
In other words, each virtual user can support multiple parallel connections. And even with one user, you can load the system so that it can not work. If you use a utility that performs only one stream (supports only one connection) for one user, then you should understand that this stream is not a real user.
Third Party Resources
You need to pay attention to the fact that Web-systems can use third-party resources. This may be analytics, counters, provided fonts, styles, javascript. Depending on your needs, you need to determine for yourself exactly what resources you need to test. In the third-party resources, any information can be initialized, which you can later use on your system. Thus, by excluding third-party resources, you will not be able to simulate completely received content for the user. The necessary list of requests can only be determined by long analysis and a deep understanding of the system under test.
The picture shows a situation where a request is made to a resource, we will consider it testable, which makes a request for something different from it. This is where we need to decide whether we need this resource in our scenario or it is not related to the Web system and we can simply exclude it.
Grouping
It is necessary to group requests for actions performed. So you can create separate groups to open the main page, to enter the system, to follow a link, etc. This is all you need mainly to establish the necessary delays between groups of actions. We consider one virtual user as a user who really works with the system. Naturally, if there are 100, 200, 1000 and more real users, each of them will spend a different amount of time on a particular page. Consequently, traffic must be uneven from virtual users. Therefore, it is necessary to establish delays between action groups. And the more real they are, the more real test results you will receive.
Conclusion
We can ignore the number of concurrent connections, third-party resources, groupings and delays. But as a result, we can get test results where it is clear that the system works with 200 virtual users (streams), but in practice you get only 10 real ones. Or get directly the opposite results, when according to the charts we see only 200 users can work with the system, but taking into account the different times of using the pages, the number of connections used and the exclusion of third-party resources, we can get 500 really working.
I believe that a clear understanding of the number of connections made, the correct use of the necessary set of resources and the delay between the groups of actions will help you to get more accurate load testing results that you will perform in yourself.
Of course, this is not a complete list of points from which preparation should begin. There are many more different aspects that somehow affect performance testing. Some of them can directly affect the agent that performs the load and may not be in any way connected with the tested Web system.
Update: we continue training in the article
Update2: we finish the preparation in the article
Source: https://habr.com/ru/post/332862/
All Articles