The difference between concurrent number and iteration in LoadRunner

Your understanding of the virtual user should be the number of iterations, the recording script will only have 1 virtual users, 1 virtual users can have multiple iterations, that is, repeat the action inside the content, in the scene settings, if you say 10 o'clock in the runtime-setting run Logic is set, that is a virtual user iteration 10 times, and asked you to set the scene duration type is run until completion, this setting will work if the type of duration is run for < time; This means that 1 users continue to perform actions inside the action during this time period. Cross-examine is not that meaning, I know the iteration, as if in the parameterization, in the table to set a number of virtual user user name and password, in the scene design, there are 10, do not know the difference between the two, that in the recording script, such as a multi-user login, where to set the number of users? Answer the user login process is not the user name and password submitted to the server, the user name of each user is different? So you record 1 users of the login, and then the user's actions to copy multiple, and then copy the user name and password are changed to unique, is not a number of users. LoadRunner inside the 1 virtual user is 1 threads (or processes), and then each thread inside the user name changed to different, starting multiple threads, is more than one user. When you write a script, you create 1 source files (the copied objects), and the controller's role is to copy multiple threads, and the user name of the copied thread is taken out of your table. Recording a script is the process of creating the first source file, and the controller is the time when multiple users are concurrently. You can start by looking at LoadRunner's user manual.

For example, in LR, I want to test 100 users concurrently logged in the time spent, then I recorded a good script, I need to parameterize "user name", "password" and in that Notepad to construct 100 real user name and password? Then run the controller and set the number of users to 100? So what is the difference between the number of iterations and the setting of 1 and 10?  I'm always confused. Test concurrent users, the difference between "iteration" and "Number of concurrent users" (the number of virtual users in the controller). Zee's answer: go back and forth in a figurative way: The four-lane road, if only four cars are traversed by the side, if the four cars in a row is the iteration, if 100 cars line up in 25 rows followed by a concurrent iteration.  In the above statement, only the side-by car is the number of users we set. The following content is reproduced, only to do a record: by using LR to do the load pressure test process found that if the different action iteration number, each time the results are different, the curve of the form is also different. This makes us confused, why do we have to set the number of iterations of the action? And how often should the iterations be set for different application systems? First you have to understand what the performance test is doing? Performance testing is the simulation of the system for a period of time the real pressure situation to investigate the performance of the system. How to simulate the real pressure of the system? For example, in half an hour, the user is logged in, and evenly distributed within this half hour. What are we going to do? Simulate the behavior of this half-hour user. How to simulate? Estimate the number of simultaneous operations and use LoadRunner to constantly send login requests, which is why we iterate. As for the number of iterations, as long as the real situation can be simulated, how many times it does not matter, but 10 times 8 times estimate is not out of the simulation. The number of iterations is at least guaranteed to run for a period of time after the pressure has reached a stable value, so that the data we get is valid. So unless it is a special requirement, we usually use the running time instead of the iteration count. 1, iterative and concurrency, are completely different concepts. It doesn't matter. For example, a user iterates 10 times, or is a user's pressure. 10 users to execute once, is the pressure of 10 users. 10 users iterate 10 times, or 10 user pressure. But they all have to do with parameterized data (also see how parameterization is set and how the system determines the commit value). 2, if you want to know how LR implements iterations and concurrency: It's a fairly easy-to-understand layer: iterations are repeated calls to the same script, repeated execution, note that for 1 users 10 times, only one memory is allocated. 10 users execute once, and the same script is called 10 times, allocating 10 blocks of memory. The LR invokes the script, compiles, runs, and sends the data by script. Like what:Web_url Such a function, execution will send an HTTP request. If you also want to know more details of the process and the implementation of the function, only side verification (the specific method to see the ability of each individual and good), because we are not the developers of LR. 3, too obvious problem, parameterized when the choice appears unique each time, as long as the parameters enough to OK, not enough, set the corresponding rules. The action iteration only works on the scene and does not work for Vuser_init and Vuser_end, and the action is the smallest unit that can be reused you can actually record all the scripts into an action, just not easy to manage. For the simplest example, like the example of LR, the booking system, if you record all the scripts into an action, then each user can only buy one ticket when they log in, and if you want a user to buy more than one ticket, it won't work. So you're going to set up multiple actions and record logins and ends in an action, and record tickets to an action so that the action of buying tickets is iterated multiple times, and the user logs on and ends only once, doesn't that simulate the reality? In fact, LoadRunner is the client's perspective to define the "response time", when the client request is sent out, LoadRunner began to calculate the response time, until it receives the server-side response. This time the problem arises: if the server-side queuing queue is full and the server resource is busy, the request resides in the server's thread, in other words, the newly generated request does not generate a real load on the server side, but unfortunately the timer for the request has been started. It is therefore easy to foresee that the response time of this request becomes very long and may even be long enough to cause the request to fail due to a timeout. By the end of the test, when we look at the results, we will find a very unfortunate phenomenon: the average response time of the transaction is very long, the minimum response time and the maximum response time of the gap is very large, and this time the average response time, in fact, lost its due meaning. In other words, because the request sent by the client is too fast to affect the actual measurement results, setting the step can alleviate the situation, so you should try to set pacing, then run to see the situation.

Number of concurrent users, there are two common misconceptions. One of the misconceptions is that the number of concurrent users is understood as the number of users who use the system, on the grounds that they may use the system at the same time, and that a closer and correct view is that the number of users online is understood as the number of concurrent users. In fact, online users are not necessarily associated with other users, such as users who are browsing the web, there is no impact on the server. However, the number of users online is one of the main bases for counting concurrent users. Concurrency is mainly for the server, whether the concurrency is the key to see whether user action on the server has an impact. Therefore, the correct understanding of the number of concurrent users is: The number of online users interacting with the server at the same time. The greatest feature of these users is the interaction with the server, which can be either unidirectional or bidirectional. For example: There is one such scenario, the system online users are 100, but at the same time to operate a certain thing (such as landing operations) the person is 20 so how to design the scene? Set up 100 virtual users in the controller to execute this script, then put a collection point before the login operation, and then set the policy for the collection point (20 users to execute the collection point when they arrive) for multiple business scenarios, as long as multiple scripts are recorded in the same scene, Then assign a different proportion of the virtual users, if you do not want to run which business scenario, then do not select this script. Cross-examine the number of concurrent users, I can be understood at the time of acquisition as the largest allowable VUser value to answer a script set VUser value, it is understood as the number of concurrent users of this business scenario, However, if you want to test the concurrency of a particular business, you  need to set the collection point, and the number of collection points cannot be greater than the VUser value.

How do loadrunner repeat iterations and how do you increase concurrency? In addition, when parameterized, for a stress test can only be used once the resources should be how to parameterize it?　　It means that these resources cannot be used once. --When parameterized, select Unique,update value on select Next row to choose each occurence, 1. Iterations are not necessarily associated with the number of virtual users iteration is like this: Iterative 1 iterations 2 iterations 3 times user 1 X1 X2 X3 user 2 Y1 X2 Y　　3 wherein the X1-3 y1-3 is the parameter, the parameter rule is the second floor said so two user is according to your rump up, for example 5 seconds on two users, then the user 1 and 2 in 5 seconds to load in, did not know to say clearly did not.　The second problem is simple, can only be used once the parameters, first of all to ensure that your parameters enough, in addition to the rule selection, note that the choice of unique iterations is only the number of iterations you set the action to iterate, and the number of users can be understood as an iteration of the entire recording process (only different users) and the increase in concurrency can be achieved by increasing the number of users can also set the collection point to increase the concurrency of an operation if a script, set the maximum concurrency of 10, 2 concurrent users per 5 seconds, and the action set to iterate 10 times: When the start to 2 seconds, the load of 2 users,　　The 2 users began to run, and both ran 10 times, regardless of whether the 2 users run 10 is the end, when the next 2 two seconds to arrive, that is, start to 4th seconds when the load of 2 users, 2 run 10 times, and then load to 10 concurrent users, and then when each user finished running 10 times the end.　　So the middle maximum concurrency is 10, but not necessarily can reach 10, because in the last few load, the previous may have been running the end, so if you want to really reach the maximum concurrency of 10 must set the collection point to complete　　However, it is not necessary to set the collection point to implement a state that is in running at the same time with 10 users. Setting up the duration is also possible.　　But that will not only run 10 times per user.　　If you want to implement a user iteration 10 times, and want to running at the same time as 10 users, you should set the collection point. The idea of iterative (iterate) design, or what we call incremental (Incremental) design, is similar to the one that XP advocates for evolutionary.

The difference between the number of concurrent and iteration in LoadRunner