Shulou(Shulou.com)06/03 Report--

Recently, I tracked a project and found that my colleagues are more keen on using the rendezvous point when performing performance tests. Conceptually, they think that if they want to get concurrent users, they must set a rendezvous point. When they execute a stress test script, they think that setting a rendezvous point is an effective concurrent user. If they do not set a rendezvous point, they think that this may not accurately represent the number of concurrent users. At present, I do not object to this view, but it makes me have a doubt, which urges me to have a deeper understanding of concurrent users and rendezvous points. I believe that most of my friends who enter the field of performance testing should have doubts. I think it is mainly due to the lack of in-depth understanding of the implementation principle of LoadRunner, and the lack of analysis of the whole process of the system. The knowledge involved includes network, protocol, middleware, database, application layer, buffer and cache and so on. Of course, it is also inextricably linked with hardware resources such as CPU queue and memory. Therefore, it is not an easy process to become an excellent performance tester, and it takes a long time to accumulate and learn. Only through a large number of project practice and analysis, and finally summed up in ideas, is it possible to become an expert in this field. Of course, I also hope that friends who really want to do a good job in performance testing will make unremitting efforts and be happy to share and discuss.

Let's take a look at the structure diagram of an application system, as shown below:

This diagram originates from teacher Xiao Bu's video and reflects the running process of an application system intuitively and succinctly, including client, network, application server and database server. each link is an indispensable element in the execution performance test analysis, and the response time process is reasonably analyzed in the structure diagram. When the request is sent from the client to the final return to the client, the processing of each link in this process may eventually become the performance bottleneck in the operation of the system, so it can be seen how important it is to understand the overall structure of the system.

Next, let's look at the definition of concurrent users and rendezvous points:

Concurrent users: in the popular sense, it is the users who operate at the same time. Of course, this "simultaneous" can be understood as the same time period and the same time point. Of course, if we say that concurrency is the users who operate at the same time at the same time, there is no error in this understanding, but in practice, there is no parallel execution in the strict sense, just like the relationship between processes and threads. Strictly speaking, only one person has the right to enforce it at a certain point.

Rendezvous point: used to synchronize virtual users to perform tasks at exactly the same time. In terms of concept, it is actually quite vague, and it is precisely because of vagueness that the use is worthy of in-depth discussion. For LoadRunner, the rendezvous point is just a strategy, and this strategy will have a lot of rules, because in reality, not all users will arrive at the rendezvous point at the same time. The above structure diagram can explain this misunderstanding, because every link from the client to the network, middleware, application layer and database has a delay, that is to say, it is impossible for all users to reach the so-called rendezvous point. To start performing operations at the same time.

From the understanding of the above two concepts, some people will wonder whether there is a relationship between concurrent users and the rendezvous point. Of course, this depends on what the requirements are, so many times we misuse rendezvous points and concurrent users, in fact, the fundamental reason lies in the understanding of the requirements, the requirements themselves do not understand what kind of scenario he wants to achieve and what kind of results he wants to achieve. Of course, we can only feel the demand and are professional technical personnel, at least most of us encounter the demand is not necessarily technical background, so they do not understand, we can not pretend to cheat, otherwise the result will definitely not be in line with the reality.

Usually, we will get the user demand that "this system should reach 200 concurrent users", which is strictly unqualified, because there are many functions for a system, such as system login, registration, query, deletion, etc., whether login is required to reach 200, or a total of 200 functions, because when users enter the system, some users are performing registration. Whether some users can operate in parallel when executing a query is also the so-called concurrency, so in order to understand the rendezvous point and concurrent number, we should fundamentally understand the business process more clearly. Only when the business is analyzed clearly can we reasonably use the rendezvous point and correctly understand the number of concurrent users.

Of course, personally, I seldom use the rendezvous point, because through the understanding of LoadRunner, I think LoadRunner itself is already simulating the process of achieving concurrency, and adding the rendezvous point setting is only for and achieving the so-called concurrency in the strict sense, but in fact, the setting of this rendezvous point does not absolutely achieve this goal, as can be proved by the process in the structure. Of course, I also use some examples to verify this. The following is the process of recording the visit to the home page of the Mercury web Tours website. The script is as follows:

Script 1: set the rendezvous point

Action ()

{

Lr_rendezvous ("synchronous access to web pages")

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

}

Script 2: do not set checkpoint

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 executing two scripts in the same scenario, it is found that the response time error is actually very small. Of course, this is only one of my practice. I have also practiced it in other projects I have done recently, including Cmax S and Bhand S. I hope that interested friends can also practice and verify ha and share the conclusions.

The point I just want to make is that it's not that the rendezvous point doesn't work in our performance tests, and if it doesn't, I'm sure the company that designed LoadRunner won't give it, but to understand how to choose to use it, which is the key. As we have mentioned before, in some application tests with complex business processes, we have to use rendezvous points, for example, in an enterprise system, the business is like this: after the user logs in, some people are improving their personal data, some are querying the data, some are performing deletion operations, and some are sending messages, and so on. In such a business, when simulating the performance test, we must make clear the relationship between the concurrent users and the rendezvous point. In the actual recording of the script, we need to divide the business into multiple transactions, and then set the rendezvous point for each different transaction. Why should we use the rendezvous point at this time? because we have to analyze the concurrency of each transaction and join 200 users. If we allow these 200 users to operate freely in this way, we will not be able to judge the number of concurrent queries, deletions, and messages, because after entering the system, there is no way to determine what 200 users have done at the same time, so this is the most reasonable place to use the rendezvous point. As for why I seldom use the rendezvous point, it also stems from this, because usually we mainly conduct stress tests on a single business, such as login or registration, a single function is just like the above access to the web page, and the script has only one operation. At this time, it is not very effective for LoadRunner to set a rendezvous point, and in order to simulate it to be closer to the actual situation. Of course, this also requires practical analysis.

Here I would like to give an example, for example, an OA system requires 200 concurrent users, and our scenario setting is that 200 concurrent users load 5 users every 10 seconds on average, running for about half an hour. We can analyze the scenario executed at this time: according to the actual situation, most of the users who log on to the OA system go to work in the morning. This is a time period, not a time point, and our simulation scenario is fully in line with the actual needs, so it is concluded that our OA system can allow 200 users to log in at the same time in 30 minutes. This shows that any requirements must be considered from the actual environment, we must also reflect the actual situation when setting the scene, in order to simulate a closer to the real scene, the results are more valuable.

Of course, performance tests should be performed with a purpose, usually for tuning, and some for evaluation.

In the performance test for the purpose of evaluation, users are more concerned about business concurrency, which is actually the concurrency of real business scenarios, in which case there is no need to set a rendezvous point.

The rendezvous point is a kind of concurrency in special cases, which is usually used in performance testing for tuning purposes, mainly for targeted pressure in order to find performance bottlenecks.

The above is purely personal understanding.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.