Reprinted from: https://blog.csdn.net/cbzcbzcbzcbz/article/details/78023327
Some time ago, the company needed to stress test the server, including the page before login and the page after login. The main purpose is to test the effect of load balancing. I don’t know if it’s because Jmeter is not as popular as loadRunner or what, there are a lot of information about Jmeter on the Internet, but most of them are the same, either simply get a page to test, or the whole article introduces a lot of third-party tools that have nothing to do with Jmeter, it looks very professional Advanced, but as a test novice, seeing such a thing is really a headache. I just want to have a good understanding of the use of Jmeter, can you give a complete introduction? I don't need to know so many other third-party tools? Can you take a picture to make it clearer? What are the parameters in this step? Corresponding to what? Why did I have a problem with this step of yours? Why don't you say a solution. . . This should be the most question in my heart when I searched for Jmeter data some time ago. When it comes to using something new, my habit is to run the process completely first. Remember, it is complete and clear. After all, others can copy and implement it according to their own needs after reading it. I have complained enough , I started to get into the topic, I explained all the pits I encountered, including how I climbed out of the pits later. . .
Step 1 Install Jmeter
The version I use is version 3.1, why is it 3.1, because there is a problem with 3.2, I also ran for a while before I know that version 3.2 is too new or something, some functions are not good, I suggest everyone here, do not use the latest version lightly , the next new version will do. After installation, there is a Jmeter.bat file in the bin directory of Jmeter, which can be run by double-clicking it.
Step 2 Use Jmeter to test the login page
After running the software, of course, we have to find a link to test it. Here we take Baidu as an example. We right-click on "Test Plan" - "Add" - "Threads (Users) - Thread Group", so that it is built There is a thread group, what is this for? Of course, it is used for running threads. After we have the thread group, we right-click the thread group, "Add" - "Configuration Element" - "HTTP Request Default Value", what is this default value for? Some common default settings can be set in it (this is not nonsense~), in the http request default value panel, we can enter the IP or domain name of the server to be tested, here we enter "www.baidu.com", the protocol is "https", if the URL you want to test starts with http, then fill in "http", and other defaults are ignored. At this time, click save in the upper left corner and a save box will pop up, which allows you to save the test configuration you have made now. If you need to test again in the future, just open the saved jmx file directly. After saving, we right-click "Thread Group" - "Add" - "Sampler" - "http request", hey, didn't you just add it? The one just now is not, the one just now is just the default value, it is just used to set some default configurations, the real request is the "http request", in the http request, we can enter the slash "/" in the "path", which means the default The path and IP column do not need to be entered, why? Because the default value of http request has been lost, you can create multiple http requests in the future, just modify the path, so that you can access different pages of the same website, this is the meaning of "default value of http request", put Just write some common settings. Next, we right-click "Thread Group" - "Add" - "Listener" - "View Results", where you can view http requests and results. Every time you create a new component and modify the configuration information, click Save. Well, the page configuration diagram is as follows:
Now we click the green run button on the toolbar to see the results in the "View Results Tree"
Our newly created "http request" returns a result of 200, indicating that the request is successful. It can be seen from the green tick that the drop-down list box in the above figure can choose the display format. We select HTML and switch to "response data" to see the return page, that is, the Baidu homepage.
Step 3 Set the number of concurrent threads
We just completed a simple test. You should also feel that you have done nothing, and you can test it. In fact, it is not. We click "Thread Group" to see the setting page of the thread group. By default, 1 thread is set, 1 Start in seconds, cycle 1 time. The number of threads indicates how many threads are started, the Ramp-Up Period indicates how long it takes to start all threads, and the number of loops indicates the number of executions of each thread. For example, I set the number of threads to 10, the Ramp-Up Period to 10, and the number of loops to 2. Indicates that the software will start 10 threads in 10 seconds, that is, 1 thread is started in 1 second, and each thread executes two requests.
In addition, we can also check "Scheduler", for example, I fill in the duration of 100, the start delay is 0, and the number of loops is checked "forever", which means that the thread starts immediately and stops after 100 seconds of execution. Note that if the duration is set time and startup delay, then the following startup time and end time will not work, so don’t worry about it, just click Run.
Step 4 Set up other listeners
Before, we only set the listener "View Result Tree". We right-click on "Thread Group" - "Add" - "Listener", there are many listeners to choose from, such as graphical results, view the results in a table , aggregated reports, etc., these are indicators that reflect the testing process. Graphical results show throughput, offset, average and other information in the form of graphs. Tabular results show the time of each request, the number of bytes returned, sent, connection time, etc., and the aggregated report shows the overall request throughput and errors. rate, etc. The image below shows the style of the table results.
It can be seen that the figure shows 20 Http requests, which are executed by 10 threads respectively, and each thread is executed twice, which is exactly in line with our thread group settings. The meaning of each column in the figure represents the request sequence number, start time, line program number, request name, time spent in the request, request status, number of bytes requested, number of bytes sent, waiting time, and connection time.
The aggregated report is shown in the figure below. The meaning of each column represents the request name, the total number of requests, the average request response time (milliseconds), the response time of 50% of the requests, the response time of 90% of the requests, and the response of 95% of the requests. time, response time for 99% of requests, minimum response time, maximum response time, bad request rate (bad requests/total requests), throughput (requests processed per second), bytes received rate, the rate of bytes sent.
Step 5 Login Test
The previous page we tested does not require login. Now let's test the login operation. Since the login operation involves specific internal URLs and parameters, I will use the general URLs and parameters instead, but the method is the same. For example, we The intranet IP is 1.1.1.1, and the login page is 1.1.1.1/login.do. We fill in 1.1.1.1 into "http request default value" and /login.do into the path of "http request". About login I want to explain the required parameters. Generally speaking, it is the user name and password, but other parameters are often required. We can use the packet capture tool Fiddler to capture packets. We log in normally on the website, which can be seen in Fiddler The post parameters required for login. For example, the post parameters of the login operation displayed in Fiddler include username, password, and type, then they need to be filled in "http request", as shown in the following figure.
Click the "Add" button to add parameters. After saving, we click Run, and we can see the page after successful login in the viewing result tree. The specific operation is the same as before.
Step 6 Session Hold
After we enter the login page, what if I want to access modules such as "My Account", "My Information", etc. These pages can only be accessed after a successful login, here we need to maintain the session, we right Click "Thread Group" - "Add" - "Configuration Element" - "httpcookie Manager", we can see the content to be added in the "Request" tab of the viewing result tree, where you can see the login requirements cookie, such as JSESSIONID, we fill JSESSIONID into the parameters of the cookie manager, as follows
At this point, we enter the URL of the logged-in page in the http request, such as "my information", etc., and the request can be successful.
Step 7 File reading URL
What we fill in the "http request" path is the webpage we want to visit, and only one page can be filled at a time. If I want to visit several webpages, such as the home page, notification page, company introduction page, etc., in addition to creating a new http request In addition, we can also store the addresses of these web pages in the TXT file, for example, I want to visit 1.1.1.1/index.do, 1.1.1.1/information.do, 1.1.1.1/company.do, we can do this
After the URL is filled in, we paste the full path of TXT to the position in the figure in "Options" - "Function Assistant Dialog" - "StringFromFile" in Jmeter, and click Generate to generate the read of the TXT file in the box. Take the path.
We paste the path starting with $ into the path of "http request", and we can access all the web pages in TXT, as shown in the figure.
Step 8 Real-time monitoring of server status
Above we have introduced several listeners that come with Jmeter. I wonder if you feel a little powerless, because none of the indicators displayed in it seem to be what you particularly need. At least for me, I am more concerned about the execution process of my request. Changes in server status, such as CPU, memory, disk, network, TPS, response time graph, etc., because this is the purpose of stress testing, and the change curve of server status with increasing requests is what we need to see more. . To see the graph of server changes, we need to download JMeterPlugins-Extras.jar and JMeterPlugins-Standard.jar, put these two jar packages under lib/ext/ in the Jmeter installation path, restart Jmeter, right-click "Thread Group" - "Add" - "Listener", we can see a lot of listeners, most of the listeners starting with "jp@gc", we choose "PerfMon Metrics Collector", which will The status information of the server is displayed. I can't see it yet. Why? Because the server to be tested needs to install a package called ServerAgent.zip. For example, my server is linux. We decompress the ServerAgent in the server and run the startAgent.sh inside. That's it, after starting up, you can see the following
The default port is 4444. I want to insert a sentence here. After I ran it, I couldn't ping port 4444 through Telnet, so it couldn't be displayed. Later, I changed it to port 4445 and started it. The specific server command is ServerAgent-2.2.3/startAgent .sh--udp-port 4445 --tcp-port 4445, this means to start the serverAgent on port 4445, you can replace 4445 with another port, if the default port 4444 does not work, you can try other ports. Well, let's go back to the Jmeter software, and fill in the server's address and port number as shown below, as well as the hardware that needs to be monitored, such as CPU, memory, disk, network, and more.
Ok, let's click Run, you can see the state change curve of the server under the chart
How about it? It's what you want. In fact, there are many other curves in the monitor. You can know it by reading English, such as TPS curve, response time curve, etc. You can add these by yourself, so I won't go into details. Well, the content of this blog is here. If there is anything wrong, please comment. Let's discuss and make progress together. Thank you!