JMeter-Goal-Oriented Scenario
In Microfocus LoadRunner, the target scenario is extremely common and can describe the target load in terms of users, hits, TPS, response time, etc. Can you do the same in JMeter? To achieve the intended goal, LoadRunner automatically adjusts the other performance metrics based on the chosen target metric. Click the link to learn more about the LoadRunner goal-oriented scenario.
There are some third-party plugins for Apache JMeter that can be used to create specific scenarios and help achieve the stated goal.
1. User-Centric Purpose (Thread)
Users in Apache JMeter are called “Threads”. If you have a typical situation where users (threads) increase at some point, perform their operations in a steady state, and then stop, you can quickly create such a scenario using the Thread Pool element.
A basic scenario that includes acceleration and steady state can be set up using the Basic Thread group element. All threads end after the trial period ends. There are some basic thread pool restrictions, including:
A. Basic thread group
It is only used to produce simple scenarios.
It is only possible to simulate acceleration and steady state (4.0 knowledge).
Wire feeding is carried out linearly and with the same delay. You can’t intensify in stages, like five threads every ten seconds, etc.
There is no option for slow throttling of threads.
The threads are disconnected once the trial period ends.
It is not capable of designing a spike test or ramp test scenario.
Iterations can end before threads complete them completely.
B. Last group of wires:
There are several third-party plugins that can help a performance tester simulate complex scenarios simply to get around the aforementioned basic thread pool limitations and achieve performance targets while producing the desired workload. The first is called “Ultimate Thread Group”. To some extent, this section can help you go beyond the limitations of the Basic Thread Pool. Conditional loading can be applied to the server using the Ultimate Thread Group.
How should the workload be configured when using “Ultimate Thread Group”?
• Download the Ultimate Thread Group plugin
• Add a feature, as seen in the GIF below.
• To add additional rows for a different number of users, click the Add Row option.
• For users 10, 20, 30, 100, 100, 100, and 100 I’m going to add 6 rows. 460 users in total.
• Check the following settings.
While Ultimate Thread Group has some useful features, the following limitations apply to this component:
• It is necessary to calculate the delay time when developing the scenario.
• Threads can terminate before the iteration is complete.
C. Concurrency thread pool:
The concurrency thread pool will replace the staggered thread pool. Unlike Stepping Thread Group, it does not create all threads at once, which saves additional memory for the acceleration phase. It serves as a good replacement for the Stepping Thread Group.
How should the “Concurrency Thread Pool” be configured for the workload?
download the Concurrency Thread Pool plugin.
Set the target concurrency (total number of threads), ramp time (minimum), number of ramp steps, and target speed time (steady state duration).
I set up the scenario for ten users in five steps and a startup time of 20 minutes. The steady-state duration is set to 60 minutes.
Check the following settings.
There are some concurrency thread group restrictions, including:
- It is only employed to produce simple scenarios.
- Simulating only ramp-up and steady-state is possible (knowledge from 4.0).
- Threads increase up in just one motif.
- There is no ability to change the threads’ ramp-down pattern.
- There is no way to design a spike test scenario.
2. Iteration Oriented Goal
The next type of goal-oriented scenario is the end-to-end journey, where a predetermined number of iterations must be completed. These objectives are necessary when a customer requests a certain number of orders, card reservations, product purchases, etc., regardless of the number of users. Note that to control the iteration rate, you also need to consider the maximum number of users you can designate. Let’s try to understand how to build an iteration-based scenario that is goal-oriented.
A. Arrivals discussion group:
This thread pool element is specially designed for the situation where the expected number of orders per hour is known. For example, 2,000 orders are placed in an online store per day, 1,000 movie tickets are reserved every hour through a mobile app, 10 software licenses are purchased per minute, etc. In this type of situation, the number of orders takes precedence over the number of orders. Number of users. Apache JMeter adjusts the number of threads based on the desired arrival rate. Here it is important to understand the arrival rate. The term “Arrival Rate” refers to the rate at which orders are shipped iteratively. If I say 10 licenses purchased in a minute, that means 10 iterations should start in a minute. The arrival rate will therefore be 10/min. If I assume 1,000 movie tickets are purchased in an hour (16.6 = 17/min), this means that about 17 iterations per minute must be started, resulting in an arrival rate of 17.
How can I tailor the “Arrivals Thread Pool” to the workload?
Visit the link to download the arrivals thread pool.
As seen in the GIF below, include it in the test plan.
Keep in mind that you need to order 3000 things in an hour or 50 products per minute.
The number of steps is 10 and the ramp time is 5 minutes.
A concurrency limit of 50 users has been set to limit the number of threads.
The thread recursion limit is left blank to allow users to run the test indefinitely.
A 60-minute holding goal is required.
Please note the following configuration:
1. Goal-Oriented Application
We must complete the specified number of requests on those goals within one hour. Performance timers can focus on these types of goals. To upgrade your memory, throughput in the Apache JMeter context refers to the rate at which JMeter sends requests or samples to the server. When the number of requests is known and the goal must be met, two key components help simulate the goal-based scenario.
A. Constant Performance Timer:
Throughout the test, this timer strives for consistent performance to meet the target. Naturally, the performance will be lower if the server cannot handle such a load. If other clocks conflict with the constant performance timer, performance may decrease. Therefore, it is not recommended to use any other timer besides the Constant Performance Timer.
How should the “Constant Throughput Timer” be configured for the workload?
As shown in the GIF below, add “Constant Performance Timer” under Test Plan.
Specify the target throughput (in samples per second) based on your performance goal.
Calculate the number of threads and add the basic thread pool.
See the settings below. There are 3 transactions with a total of 15 samples (requests). There are 5 threads and the exam lasts 5 minutes. 120 samples per minute are available at the target throughput.
b. Throughput Shaping Timer:
Another timer called the “Performance Modeling Timer” can be added to the test plan to build a goal-based scenario where the goal is to achieve the required RPS (Requests Per Second) with distributed load to exceed the limitations of the Performance Modeling Timer. constant bypass performance. The same scenario configuration options were used for the Ultimate Thread Group and the Free-Form Arrivals Thread Group. The only distinction between these 3 JMeter components is:
In Ultimate, the thread speed is staggered. Distribution of thread pool iteration rate in free-form arrivals The performance modeling timer distributes the thread pool request rate (samples).
How do you configure the “Performance Configuration Timer” for the workload?
Use the performance modeling timer plugin.
Consider the request to develop a spike test to compare the load of 150 and 300 requests at different times. A 100 RPS load is typical.
To set the stage, click the Add Row button and then add rows.
Please note the following configuration:
