Some basic knowledge of scene design has been described above. In view of the importance of scene design in the entire performance test process, there are of course many use skills or some advanced use methods in the actual use process. These skills or advanced usage methods can help us to better design the scene or monitor the execution of the scene. This chapter mainly explains some of the commonly used skills in the scene design process, the main contents are:
Meeting point settings
IP spoofing technology
Load balancing technology
Perform path conversion
Use functional test scripts in LoadRunner
Meeting point
First of all, it is necessary to clarify why the set point is set during the performance test. In the LoadRunner test process, there is actually no guarantee that all Vusers are really operating at the same time. This will not achieve the purpose of concurrent testing, so you need to use it Rendezvous technology. Rendezvous means that if a rendezvous is set before an operation, LoadRunner will wait for all Vusers to be ready to perform the function before starting execution, which emphasizes that all Vusers are ready If only some Vusers are ready, this function will not be executed.
Meeting point settings
Select Scenario→Rendezvous, as shown in the figure.
Next, the meeting point information dialog box will pop up, as shown in the figure.
Rendezvous: This shows all the rendezvous points contained in the script. These rendezvous points are enabled by default. You can click the button to set the assembly point to a disabled state.
Scripts: shows all scripts running in the scene.
Vusers: Set virtual users in the scene running. By default, all Vusers will participate in the rendezvous policy. You can manually click the button to set some Vusers not to participate in the rendezvous policy.
Click the button, the system will pop up the Policy dialog box, as shown in the figure. In this dialog box, you can set the rendezvous execution strategy.
The first item: indicates that when X% of all users reaches the rendezvous, the waiting users will be released and the scene will continue.
The second item: indicates that when X% of the currently running users reaches the rendezvous point, the waiting users will be released and the scene will continue.
The third item: indicates that when X users arrive at the rendezvous point, they start to release the waiting users and continue to execute the scene.
There is also a Timeout between Vusers. For 30 seconds, when the first user arrives at the rendezvous point, wait for another 30 seconds. If the number of users arriving within 30 seconds reaches the specified number, the scene will continue to execute. If the specified number of users is not reached within 30 seconds, no longer wait, start to release the waiting users and continue to execute the scene, as shown in the figure.
As can be seen from the above figure, after the current three virtual users arrive at the rendezvous point, the fourth virtual user does not arrive at the rendezvous point within 30 seconds, so that the virtual users that have already arrived will not wait for the next virtual users. Instead, release the virtual user directly and run the following script.
The above are all situations where the Vuser release is controlled automatically, but in the actual use process, the Vuser can also be released manually, which involves the manual release of the Vuser technology. Under normal circumstances, you will find that the following Release button is not available in the assembly point information dialog box, as shown in the figure. 
The following are the steps to manually release Vusers:
1. Start executing the scene.
2. Choose during the scene execution
Scenario→Rendezvous
Open the meeting point information dialog box.
3. While the scene is running, the buttons below and
The button will become available, and you can click
Button to manually release the Vuser, as shown in the figure.
Relation between rendezvous point and transaction
It is necessary to set the rendezvous point during concurrent testing. At the same time, in order to obtain the response time of the transaction, the start and end transactions must be added. Then the rendezvous point is set after the start transaction code or before the start of the transaction? What is the relationship between the two?
In the first case, the rendezvous is set after the start transaction code, and the process diagram of its operation is shown in the figure.
From the figure above, you can see that when the virtual user runs to the starting point of the transaction, the transaction starts to count the time, but a careful study found that when the first virtual user reaches the rendezvous point, the following virtual users have not yet reached the rendezvous point. The first virtual user has to wait for other virtual users to reach the rendezvous before it can continue to run, but before the virtual user arrives at the rendezvous, the transaction has been counting time and is not paused, so the waiting time is not the real transaction at all. Time, the real transaction response time should remove the waiting time between virtual users.
In the second case, the rendezvous point is set before the start transaction code, as shown in the figure.
As can be seen from the above figure, although it is necessary to wait for all virtual users to reach the rendezvous before releasing the virtual users, the transaction does not start timing at this time, and the timing will only start when it runs to the start of the transaction code. The time value of does not include the waiting time wasted by virtual users due to the assembly point.
So in summary, generally set the rendezvous point before the start of the transaction code.