JMeter calculates the number of concurrent users according to the load instance

Table of contents

       Foreword:

  Business needs

  analysis needs

  Test Model Construction & Use Case Design

  1. Scenario construction: login business operation process, attendance check-in operation process;

  2. Scenario use case design

  3. Test script use case design:

  model building

  Log in and check in - operation process:

  Scene design

  Types of common test scenarios:


       Foreword:

JMeter is a commonly used performance testing tool that tests system performance by simulating real user scenarios. Before testing, it is necessary to determine the number of concurrent users required to ensure the reliability and accuracy of the test.

  Business needs

  Suppose the company leader now assigns you a performance test requirement as follows:

  1: There are 1,000 people in the company who will log in to the platform to check in during working hours, and may log in and check in multiple times

  2: Business peak hours are between 8:00-8:30, half an hour

  3: It is necessary to ensure that the response time of 90% of users is within 1s

  4: It is guaranteed to support the completion of 5,000 check-in transactions within half an hour, and at the same time, 90% of the business time does not exceed 1 second. How much can the maximum number of concurrent transactions of the system reach within half an hour? What is the maximum number of concurrent users per second?

  analysis needs

  a. 1000 people log in within 30 minutes, then 1000/30=33 people log in every minute, and 0.56 people log in every second, that is, 1 person logs in in 2s;

  b. 5000 check-in transactions are completed within 30 minutes, then 5000/(30*60)=2.78 check-in transactions need to be completed per second;

  In general, within half an hour, one person logs in every 2s, and there are 3 check-in transactions per second; that is, the thread duration is 30 minutes, and check-in tps=3;

  Circulate once, login 317ms+ clock in 976ms=1293ms, 0.77 iterations can be performed in 1 second; 1392 iterations can be performed in 30 minutes; 1 thread for login request can meet the requirements;

  If you want to complete 5000 punches in 30 minutes, you need 5000/1392=3.6 concurrent threads, that is, 4 threads; 

  In the actual request, it is also necessary to consider the time for entering the account password when logging in, and a timer can be added;

  Test Model Construction & Use Case Design

  This requirement is a typical scenario for calculating the number of concurrency based on the load. First, we need to design a business scenario;

  1. Scenario construction: login business operation process, attendance check-in operation process;

  2. Scenario use case design

  1. Test scenario type:

  Single business benchmark test, single business stress test, single business load test;

  Comprehensive business benchmark test, comprehensive business stress test, comprehensive business load test;

  2. Determination of the number of business threads:

  Login business - determine the number of threads, check in attendance - determine the number of threads;

  3. Test scenario use case design:

  Login concurrent-scenario use case, login business volume-scenario use case, concurrent attendance-scenario use case, attendance check-in business volume-scenario use case;

  3. Test script use case design:

  Login-script use case, attendance punch-script use case;

  model building

  Login business - operation process

  a) access to the login page;

  b) Enter the account number and password, click [Login], and jump to the home page;

  c) Click [Exit] to jump to the login page;

  Log in and check in - operation process:

  a) access the login page;

  b) Enter the account number and password, click [Login], and jump to the home page;

  c) Click [Attendance Management] to enter the attendance home page;

  d) Click [Punch Card];

  e) Enter the attendance check-in page to check the check-in records;

  e) Click [Exit] to jump to the login page;

  Scene design

  In the process of performance testing, you should first design the test scenario, and then design the script for the scenario. In order to truly reflect the performance problem of the object under test, it is necessary to simulate the business scenario where the object under test may have a bottleneck as much as possible. Then design test scenarios for the business;

  Types of common test scenarios:

  There are usually several common test scenarios for performance testing: single business benchmark test, single business stress test, single business load test, comprehensive business benchmark test, comprehensive business stress test, comprehensive business load test;

  1) Benchmarking

  Test whether a specific business meets the system design or the performance indicators expected by users; benchmark tests can be concurrency benchmarks and business volume benchmarks;

  For example, it is expected that the login interface can support 500 users to log in concurrently, and the response time should not exceed the required value. If it is satisfied, the benchmark test is considered complete, otherwise it fails;

  2) Stress test

  Test the duration of continuous service of a specific business under the maximum load to verify the stability of the tested business;

  The load designed during the stress test is based on the system benchmark test. For example, if the maximum concurrency of the login interface is 500 concurrent, the load of the stress test is designed to be 500; through the change of the running time, verify that the server is under the maximum load of the system Ability to continue serving;

  3) Load test

  Test the maximum load that a specific business can bear, and verify the maximum load that the tested business can bear;

  If the maximum concurrent system benchmark test is 500, then through multiple tests, gradually increase the load, and finally obtain the optimal load of the business under test. Under the optimal load, the system needs to meet various performance indicators;

  Log in and punch in 345ms*5=1725ms

  After adding the transaction controller, it takes 1397ms to log in and check in

  In actual situations, it is also necessary to consider the following situations of thinking time, such as:

  The user enters the user name and password: 5s;

  Waiting time after opening attendance: 2s;

  Simulate thinking time with a timer;

  Then the time (t) required to log in once is 1.397+5+2=8.397s;

  Then 30 minutes (T) can iteratively log in and clock in the number of times = 30*60/8.397=214.36; actually need 5000 transactions;

  The number of threads to be set = 5000/214.36 = 23.32, in order to ensure >= 5000 transactions, so the number of threads is 24; the number of threads = 5000/(60*T/t)=5000*[t/(60*T)]

  It can be concluded from this: Thread = BC*[t/(60*T)],

  BC: business number/business volume, in this example BC=5000;

  t: Time consumed by a single user for a single service, simulating the real behavior of a real user as much as possible, in this example t=8.397s;

  T: length of inspection, in this example T=30 minutes;

  Regarding Thread, the calculation here is the number of threads required. In fact, this formula calculates the average number of concurrency per unit time. That is, how many users or threads concurrently initiate requests to the server per unit time;

  If you log in to the punch card business scenario, the calculation is 24.

  In jmeter, it is indicated that the system needs an average of 24 threads to initiate requests at the same time to support the corresponding business volume in the corresponding time period;

  In a real user scenario, it means that a maximum of 24 users can initiate requests at the same time on average per second to support the corresponding business volume in the corresponding time period;

  This calculation evaluates concurrency

  Corresponding peak concurrency: Thread_Max = Thread + 3* root number Thread

  If the average concurrency is 24, then Thread_Max = 24 + 3*root 24 = 38.7, and the peak concurrent users per second is about 39.

As someone who has been here, I also hope that you will avoid some detours. Here I will share with you some necessities on the way forward for automated testing, hoping to help you. (WEB automated testing, app automated testing, interface automated testing, continuous integration, automated test development, big factory interview questions, resume templates, etc.), I believe it can make you better progress!

Just leave [Automated Test]

Guess you like

Origin blog.csdn.net/Free355/article/details/131326954