Netizen question:
For example, in LR, I want to measure the time it takes for 100
users to log in simultaneously . Do I need to parameterize the " username", "password" and construct 100 real users in that notepad after recording the script ? name and password? Then run the Controller, set the number of users to 100? So how to set the number of iterations here, what is the difference between setting it to 1 and setting it to 10? I am always confused about the difference between testing concurrent users, "iteration" and "number of concurrent users" (that is, the number of virtual users set in the controller).
ZEE's answer:
Go back and forth in a metaphorical way: on
a four-lane road, if only four cars walk side by side, it is concurrent;
if four cars walk in a column, it is iteration;
if 100 cars walk in 25 rows, it is concurrent Add iteration.
In the above statement, only the side-by-side car is the number of users we set.
a four-lane road, if only four cars walk side by side, it is concurrent;
if four cars walk in a column, it is iteration;
if 100 cars walk in 25 rows, it is concurrent Add iteration.
In the above statement, only the side-by-side car is the number of users we set.
The following content is reproduced, just for the record:
Through the load
stress test process with lr, it is found that if different number of action iterations are set, the results obtained each time are different, and the representation of the curve is also different. This makes us feel confused, why do we need to set the number of iterations of the action? And how to set the number of iterations for different application systems?
First of all you need to understand what performance testing is doing?
The performance test is to simulate the real stress situation of the system for a period of time to examine the performance of the system.
Let's see how to simulate the real pressure situation of the system? For example, within half an hour, users are logging in, and they are evenly distributed within the half hour. What are we going to do? Simulate the user's behavior for half an hour. How to simulate? Estimate the number of people operating at the same time, and use LoadRunner to continuously send login requests, which is why we iterate.
As for the number of iterations, as long as the real situation can be simulated, it does not matter how many times, but it is estimated that 10 times and 8 times cannot be simulated. The number of iterations must at least ensure that the pressure reaches a stable value and then run for a period of time, so that the data we get is valid. Therefore, unless we have special requirements, we generally do not use the number of iterations, but the running time.
1. Iteration and concurrency are completely different concepts. It doesn't matter.
For example, if a user iterates ten times, it is still the pressure of a user.
10 users to execute once, is the pressure of 10 users. 10 users iterates 10 times, still the pressure of 10 users. But they are all related to the parameterized data (also depends on how the parameterization is set, and how the system judges the submitted value).
2. If you want to know, how does LR achieve iteration and concurrency:
say a relatively easy-to-understand level: iteration is to repeatedly call the same script and execute it repeatedly. Note that for 1 user to execute 10 times, only Allocate a block of memory. If 10 users execute it once, the same script is called 10 times, and 10 blocks of memory will be allocated. LR calls the script, compiles it, runs it, and sends data according to the script.
For example, a function such as web_url will send an HTTP request when executed.
If you still want to know the implementation of more detailed processes and functions, you can only verify them side-by-side (the specific method depends on each person's ability and expertise), because we are not developers of LR.
3. The problem is too obvious. When parameterizing, the selection is unique each time. As long as the parameters are enough, it is OK. If the parameters are not enough, set the corresponding rules.
Iteration only works on the action in the scene running, it has no effect on vuser_init and vuser_end. Action is the smallest unit that can be reused. In fact, you can record all scripts into one action, but it is inconvenient to manage.
For the simplest example, like the example that comes with lr - the ticket booking system, if you record all scripts into one action, then during playback, each user can only buy one ticket after logging in, and if If you want a user to buy multiple tickets, this will not work. Then you need to set up multiple actions, and record the login and end in one action, and record the ticket purchase in one action, so that the action of buying tickets is iterated multiple times, and the user login and end only run once. Doesn't this simulate the real situation?
In fact, LoadRunner defines "response time" from the perspective of the client. When the client request is sent, LoadRunner starts to calculate the response time until it receivesserver-side response. At this time, the problem arises: if the queuing queue on the server side is full and the server resources are busy at this time, then the request will reside in the thread of the server, in other words, the newly generated request will not There is a real load on the server side, but unfortunately the timer for this request has already started, so we can easily foresee that the response time of this request will become very long, maybe even so long that the request Failed due to timeout. After the test is over, when we check the results, we will find such an unfortunate phenomenon: the average transaction response time is very long, and the gap between the minimum response time and the maximum response time is very large, and the average response time at this time is actually the same. lost its meaning. That is to say, the actual measurement result is affected by the request sent by the client too fast. Setting the step size can alleviate this situation. In this way, you should try setting pacing and run it again to see the situation.
First of all you need to understand what performance testing is doing?
The performance test is to simulate the real stress situation of the system for a period of time to examine the performance of the system.
Let's see how to simulate the real pressure situation of the system? For example, within half an hour, users are logging in, and they are evenly distributed within the half hour. What are we going to do? Simulate the user's behavior for half an hour. How to simulate? Estimate the number of people operating at the same time, and use LoadRunner to continuously send login requests, which is why we iterate.
As for the number of iterations, as long as the real situation can be simulated, it does not matter how many times, but it is estimated that 10 times and 8 times cannot be simulated. The number of iterations must at least ensure that the pressure reaches a stable value and then run for a period of time, so that the data we get is valid. Therefore, unless we have special requirements, we generally do not use the number of iterations, but the running time.
1. Iteration and concurrency are completely different concepts. It doesn't matter.
For example, if a user iterates ten times, it is still the pressure of a user.
10 users to execute once, is the pressure of 10 users. 10 users iterates 10 times, still the pressure of 10 users. But they are all related to the parameterized data (also depends on how the parameterization is set, and how the system judges the submitted value).
2. If you want to know, how does LR achieve iteration and concurrency:
say a relatively easy-to-understand level: iteration is to repeatedly call the same script and execute it repeatedly. Note that for 1 user to execute 10 times, only Allocate a block of memory. If 10 users execute it once, the same script is called 10 times, and 10 blocks of memory will be allocated. LR calls the script, compiles it, runs it, and sends data according to the script.
For example, a function such as web_url will send an HTTP request when executed.
If you still want to know the implementation of more detailed processes and functions, you can only verify them side-by-side (the specific method depends on each person's ability and expertise), because we are not developers of LR.
3. The problem is too obvious. When parameterizing, the selection is unique each time. As long as the parameters are enough, it is OK. If the parameters are not enough, set the corresponding rules.
Iteration only works on the action in the scene running, it has no effect on vuser_init and vuser_end. Action is the smallest unit that can be reused. In fact, you can record all scripts into one action, but it is inconvenient to manage.
For the simplest example, like the example that comes with lr - the ticket booking system, if you record all scripts into one action, then during playback, each user can only buy one ticket after logging in, and if If you want a user to buy multiple tickets, this will not work. Then you need to set up multiple actions, and record the login and end in one action, and record the ticket purchase in one action, so that the action of buying tickets is iterated multiple times, and the user login and end only run once. Doesn't this simulate the real situation?
In fact, LoadRunner defines "response time" from the perspective of the client. When the client request is sent, LoadRunner starts to calculate the response time until it receivesserver-side response. At this time, the problem arises: if the queuing queue on the server side is full and the server resources are busy at this time, then the request will reside in the thread of the server, in other words, the newly generated request will not There is a real load on the server side, but unfortunately the timer for this request has already started, so we can easily foresee that the response time of this request will become very long, maybe even so long that the request Failed due to timeout. After the test is over, when we check the results, we will find such an unfortunate phenomenon: the average transaction response time is very long, and the gap between the minimum response time and the maximum response time is very large, and the average response time at this time is actually the same. lost its meaning. That is to say, the actual measurement result is affected by the request sent by the client too fast. Setting the step size can alleviate this situation. In this way, you should try setting pacing and run it again to see the situation.
The article is reproduced to: http://www.51testing.com/html/27/476227-821855.html