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

Scene:

You should have found out when using Jmeter testing.

(1) when a thread starts, it will send a test request directly;-- if you want to simulate a high concurrency test in an instant, you need to increase the number of threads, which consumes the performance of the test machine, and often cannot support a large number of concurrency. Cannot control the amount of instantaneous concurrency of each test.

(2) if constant throughput timer is used, the concurrency test can be simulated for a long time, but it still cannot satisfy the stable instantaneous high concurrency test.

Resolve:

1. Use rendezvous points

Function: block threads until the specified number of threads arrive, and then release them together, which can cause a lot of pressure in an instant.

To quote the insect division, "the Red Army platoon leader said: wait a minute! after gathering all the comrades-in-arms, let's rush together! this puts the greatest pressure on the enemy."

Operation steps

1. Add a rendezvous point, which is synchronized timer in Jmeter

2. Panel description and settings

(1) Panel description

1) name: custom name

2) Number of Simulated Users to Group by

Define how many simulated users trigger the release of the synchronizing block (default value of '0'means all users).

That is, a. Send a test request after the number of simulated users (threads) per set

b. If set to 0, it is equivalent to the number of threads set to thread rent

c. Make sure that the value set is not greater than the number of users (threads) contained in its thread group-- assemble threads without issuing test requests until the timeout (if set).

The example shows that "Number of Simulated Users to Group by: 5" indicates that the concurrency is 5. In other words, Jmeter will wait until all five threads are running here before the five threads begin to perform the later operations, and the threads that arrive first will wait here.

3) Timeout in milliseconds

If set to 0,no timeout will occur;if superior to 0,then if after the timeout interval the number of users waiting is not reached,timer will stop waiting.

That is, a. Timeout, that is, the number of milliseconds after which the assembled thread is released at the same time to send a test request

b. If set to 0min timer, it will wait until the number of threads reaches the value set in "Number of Simultaneous Users to Group" before releasing. If it is greater than 0, then if the maximum wait time (in milliseconds) set in Timeout in milliseconds is exceeded and the value set in "Number of Simultaneous Users to Group" is not reached, Timer will no longer wait and release the thread that has arrived.

(2) set up

We set Number of Simulated Users to Group by: 10 here

Timeout in milliseconds: 500

3. Set thread group properties

Because the collection point is now used to achieve high concurrency testing, the thread can now be set in the thread group properties to start over a longer period of time, so that the pressure on the test machine is relatively less.

4. Add related requests, result trees, etc., and run to view the results.

As you can see from the result tree, the request is executed in batch

1) start the script execution and observe the trend of the increase in the number of requests

Or

2) compare the sending time of the request

4. Other practices

(1) practice applying 1--synchronizing timer to one of multiple sampler

If you want the timer to be applied to only one of the sampler, add the timer as a child node, as shown in the following figure

The timer works only on HTTP request 1 on it, that is, the timer is executed only before HTTP request 1 is executed, regardless of HTTP request 2.

(2) practice applying 2--synchronizing timer to multiple sampler

As follows, synchronization timers 1 and 2 are executed before HTTP request 1 and HTTP request 2 are executed. Timers in the same scope as sampler are executed before a sampler is executed

Pay attention

1. Some people on the Internet said, "the location of the rendezvous point can only take effect before the Sample (sampler)."

This is not true. In Jmeter, timer is executed before sampler. Whether the timer is placed after or before the sampler. Of course, if there is more than one timer, the timer will be executed in the same scope, so the order of timer needs to be carefully placed.

However, for better readability, it is recommended that the timer be placed in front of the corresponding sampler or in the child node

2. Synchronizing timer only works on threads in the same JVM.

So, if you use concurrent testing, make sure that the value set in "Number of Simultaneous Users to Group by" is not greater than the number of users contained in its thread group.

(original text: Synchronizing timer blocks only within one JVM, so if using Distributed testing ensure you never set "Number of Simultaneous Users to Group by" to a value superior to the number of users of its containing Thread group considering 1 injector only)

Just think: a. If synchronizing timer works on all jvm during distributed testing, then the jvm or the parts that monitor the work of the jvm need to communicate frequently to determine the number and status of threads, and then after enough threads are assembled, they have to send a signal to the Jmeter to send the test request, with a delay in the middle, so that more real high concurrency cannot be simulated, and this thing will consume some of the performance of the test machine. Will have a negative impact on the test results.

So for the time being, it only supports the control of a single jvm. If there is a solution to the above problems, you can control multiple jvm and control the total concurrency.

b. If distributed testing is performed and Synchronizing timer is used, and the value is set to less than the number of threads in a single jvm

However, it is difficult to ensure that all jvm assemble the same number of threads at the same point in time, so it is difficult to draw a test conclusion because the performance under concurrency is unknown; of course, the enabling time of threads can be extended and the timeout period can be extended, which is likely to assemble enough threads at the same time to achieve ultra-high concurrency testing.

Therefore, distributed testing and Synchronizing timer are not generally used at the same time; if necessary, the relevant parameters need to be set carefully.

3. If Timeout in milliseconds is set to 0 and the number of threads cannot reach the value set in "Number of Simultaneous Users to Group by", then Test will wait indefinitely unless terminated manually.

There are several kinds of situations that cannot be achieved:

a. The value set is greater than the number of threads, so it can never be reached

b. The number of the last batch of threads is not enough for the number of collection points.

Thank you for reference:

(1) zjq001X (11) jmeter- rendezvous point-study notes: http://blog.csdn.net/zjq001x/article/details/53107159

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.