Discuss concurrent users and integration points of LoadRunner

Recently, I tracked a project and found that my colleagues are keen on using the set point when performing performance tests. In terms of concept, I think that to get concurrent users, I must set the set point. I think that when executing a stress test script, if the set point is set, it is a valid concurrent user. If the set point is not set, it is deemed that this cannot accurately represent the number of concurrent users. At present, I am opposed to this point of view, but it gives me a kind of doubt, prompting me to have a deeper understanding of concurrent users and integration points, I believe that most of my friends in the performance testing research field should be confused. The main reason is that I still don't have a deep understanding of the implementation principle of LoadRunner and lack of analysis on the entire process of the system, the knowledge involved includes the network, protocol, middleware, database, application layer, buffer and cache. Of course, it is also closely related to the CPU queue and memory of hardware resources. Therefore, it is not easy to become an excellent performance tester. It takes a long time to accumulate and learn, only through a large number of project practices and analysis, finally, I will sum up my thoughts to become an expert in this field. Of course, I also hope that all my friends who really want to do a good job in performance testing will make unremitting efforts to share and discuss this.

First, let's look at the structure of an application system, as shown below:

This figure is from the video provided by instructor Tom. It intuitively and concisely reflects the running process of an application system, including the client, network, application server, and database server, each stage is an essential element in the performance test and analysis. The structure chart also analyzes the response time processing process based on a reasonable score. When a request is sent from the client, it is finally returned to the client, in this process, the processing of each link may eventually become a performance bottleneck in system operation. Therefore, we can see how important it is to understand the overall structure of the system.

Next, let's take a look at the definition of concurrent users and integration points:

Concurrent users: in the general sense, they are users who operate at the same time. Of course, this "same time" can be understood as the same time period and the same time point, of course, if concurrency is the user who operates at the same time point, there is no error in this understanding, but in actual situations, there is no strict concurrency execution, just like the relationship between processes and threads, at a certain point, only one person has the right to execute.
Set point: used to synchronize virtual users so that tasks can be executed exactly at the same time. In terms of concept, this is actually vague. It is worth further exploration because of its fuzzy usage. For LoadRunner, the set point is just a policy, and there are many rules for this policy, because not all users will arrive at the set point at the same time in actual situations, the structure above can explain this misunderstanding, from the client to the network, middleware, and application layer to the database, there is a delay in each of these steps. That is to say, it is impossible for all users to reach the so-called collection point and start to execute operations at the same time.
From the above two concepts, some people will think about whether there is any relationship between concurrent users and the set points. This is the key. Of course, this depends on what the demand is. So the root cause of misuse of collection points and concurrent users is our understanding of the demand, the demand itself does not know the scenario he wants to implement and what results he gets. Of course, we can only feel that we need professional technical personnel. at least most of us may not be technical personnel, so if they don't understand it, we can't hide it, otherwise, the result is definitely not in line with the actual situation.

In general, we will get the user's requirement that "the system should reach 200 concurrent users". This requirement is strictly unqualified, for a system, there are many functions, such as system logon, registration, query, and deletion. Do they require 200 logon or 200 of all functions in total, because when a user enters the system, some users are performing registration, some users are performing queries, and whether they can perform parallel operations is also known as concurrency. Therefore, we need to understand the set points and concurrency, fundamentally, we should have a clearer understanding of the business process. Only by clearly analyzing the business can we reasonably use the collection points and correctly understand the number of concurrent users.
Of course, as far as I am concerned, I seldom use a set point. Because of LoadRunner's understanding, I think LoadRunner is already simulating a concurrent process, the purpose of adding a set point is to achieve the so-called concurrency in a strict sense. The actual setting of this set point is not absolutely achieved, and the process in the structure can be proved. Of course, I also used some examples for verification. The following is a script for accessing the home page of mercury Web tours website during recording:

Script 1: Set the set point

Action ()
{

Lr_rendezvous ("synchronously accessing Web pages ");

Lr_start_transaction ("START ");

Web_url ("mercurywebtours ",
"Url = http: // 192.168.3.34: 1080/mercurywebtours /",
"Resource = 0 ",
"Reccontenttype = text/html ",
"Referer = ",
"Snapshot = t1.inf ",
"Mode = html ",
Last );

Lr_end_transaction ("START", lr_auto );

Return 0;
}

Script 2: do not set the set point

Action ()
{
Web_url ("mercurywebtours ",
"Url = http: // 192.168.3.34: 1080/mercurywebtours /",
"Resource = 0 ",
"Reccontenttype = text/html ",
"Referer = ",
"Snapshot = t1.inf ",
"Mode = html ",
Last );

Return 0;
}

After two scripts are executed in the same scenario, it is found that the response time error is very small. Of course, this is only one of my practices. I have also practiced other projects recently, including both C/S and B/S, if you are interested, you can share your conclusions.

The above is just a point I want to express that it is not the integration point that does not play a role in our performance testing. If it does not, I believe that companies that design LoadRunner will not give it out, but to understand how to choose to use it, this is the key. As we have mentioned before, in some application tests with complicated business processes, we must use a collection point. For example, the business in an enterprise system is like this: After a user logs on to the system, some are improving personal data, some are querying data, others are deleting data, and some are sending messages. In such a business, when simulating a performance test, the relationship between the concurrent user and the set point must be clearly defined. During the actual script recording, we need to divide this business into multiple transactions, and then set a collection point for each different transaction. Why should we use the collection point at this time, because we have to analyze the concurrency of each transaction. After 200 users are added, we will allow these 200 users to operate freely, it is impossible to determine the number of queries concurrency, the number of deleted concurrency, and the number of sent message concurrency, because after entering the system, it is impossible to determine what the 200 users have done at the same time, therefore, this is the most reasonable place to use the collection point. As for why I rarely use the integration point, it also comes from this, because we usually perform stress tests on a single business, such as login or registration, A single function is like accessing the web page above. The script only has one operation. For LoadRunner, it is not very effective to set the set point. In order to simulate the actual situation, of course, this is also the actual analysis.

Here I would also like to give an example. For example, an OA system requires 200 concurrent users, and our scenario is set as follows: 200 concurrent users load 5 users every 10 seconds on average, it takes about half an hour to analyze the execution scenario: according to the actual situation, most of the users logging on to the OA system usually go to work ~ , This is a time period, not a time point. Our simulation scenario is completely in line with the actual needs, so it is concluded that within 30 minutes, our OA system allows 200 users to log on simultaneously. It can be explained that any requirement must be put forward from the actual environment, and we must reflect the actual situation when setting the scenario to simulate a scenario closer to the real world, the results are more valuable.

Of course, the execution of performance tests should be purposeful, usually for tuning, and some for evaluation

In performance tests aimed at evaluation, users are more concerned with business concurrency, which is actually the concurrency of real business scenarios. In this case, you do not need to set a set point.
The set point is a concurrency in special circumstances. It is usually used in performance tests for optimization purposes. It is mainly used to apply pressure to locate performance bottlenecks.

The above is my personal understanding and we look forward to making a brick!