Before using JMeter, learn about the internal principles of JMeter for better use of the tool.

1. JMeter architecture

The structure diagram of JMeter is as follows:

  • X1 Sampler: The Sampler is used to send HTTP requests to the server and receive the response data from the server. JMeter sampler has many original components (sampler is called component, and a specific sampler such as HTTP sampler is called component), which basically covers common protocols, such as HTTP, FTP, JAVA, JMS, LDAP, MAIL, MongoDB, SMTP, SOAP, TCP, JUnit, etc.
  • X1 Assertions: Assertion is used to verify whether the result is correct, that is, whether the request is successful or not, whether the returned data meets the requirements, etc. By comparing the preset result with the actual returned result, the assertion is successful. JMeter’s assertion component also has various components, such as response assertion, XML assertion, BeanShell assertion.
  • X1 Listener: the Listener is used to collect test results. The Listener has two tasks, that is, adding the result Listener and displaying the result. The Listener component also has a variety of components.

Samplers + assertions + listeners, combined to send requests, validate results, and log results;

  • X2 Processors: Pre Processors are used to prepare environments and parameters before a request is sent, such as setting up a database connection before operating on a database.
  • X2 Config Element: The configuration Element is used to provide preliminary data for the sampler, such as parameterizing, generating dynamic data, or reading test data from files, etc.
  • X2 Post Processors. Post Processors are used to process data from server responses, such as retrieving the login session_ID. Post Processors are placed after the sampler.

The preprocessor, configuration component, and post-processor are all supported by the sampler, which focuses on the business logic.

  • Logic Controller X3: The Controller is used to control the execution Logic of the sampler, such as the execution sequence and the execution times. The combination of various controllers can also fulfill various strange requirements
  • X4 Timer: The Timer is used to complete the functions of the collection. For example, in order to realistically simulate the user load, it is necessary to simulate the sending of these requests at the same time. The Timer also has many kinds of components.
  • X5 Threads: Thread groups are used to simulate large user loads. You can set the number of Threads to run (one user per thread), duration, timing, etc.

The Y dimension is actually a partition of performance tests, with Y1 being the part that simulates user requests and Y2 being the part that validates the results. Since both parts require thread groups, they intersect.

The Z-dimension has only one Listener, which is used to collect results. Listeners can be placed not only inside the thread group, but also outside the thread group, so they intersect with them.

2. Operation principle of JMeter

JMeter runs in a threaded manner, using thread groups to drive multiple threads to run test scripts and load the servers under test. Each load machine can run multiple thread groups.

JMeter scenarios can be divided into two types based on the operation mode:

  • GUI: Graphical user interface running mode, visualization, more intuitive, using the mouse operation, convenient real-time view of the running status, such as test results, number of running threads, etc.
  • For example, in non-gui mode, 100 threads can generate 100TPS of load, while in GUI mode, only 80TPS of load can be generated.

So every time you start JMeter, you’ll get the message “Don’t use GUI mode for Load testing!”

Based on the operation architecture, it can also be divided into two kinds, namely, localized operation or stand-alone operation, remote operation, whether in GUI mode or non-GUI mode, both local operation and remote operation are supported.

  • Run locally: Run only one JMeter machine, with all requests coming from one machine;
  • Remote operation: a JMeter controller (Master) controls remote machines (Slave) to generate load;
  • Load machine: the machine that initiates load requests to the server under test. Like other test tools that support remote operation, the load machine is managed by the control machine and starts a client Agent program first. The control machine can take over the load machine.
  • Control machine: control machine is also a load machine, but is a load machine was selected as the management machine of that machine, so the control machine can also participate in the script operation, while the management and command remote load machine operation task, and collect remote load machine test results;

The logic to run remotely is:

  • Start Agent program (run jmeter-server.bat);
  • Connect the control machine to the remote load machine (modify the configuration file, it will automatically detect and connect);
  • The controller sends instructions (scripts and start commands) to start the thread (parameterized files or dependent packages need to be manually copied to the remote loader);
  • Load machine runs the script, return the status (including test results);
  • Control machine to collect results and display;

3. Elements of the JMeter test plan

A script in JMeter is both a test plan and a snap-in. JMeter’s request emulation and concurrency Settings (that is, the number of threads set, with one thread representing one virtual user) are all set together in the script file.

  • Element 1: There can be only one test plan in a script
  • Element two: There must be at least one thread group in the test plan
  • Element three: There must be at least one sampler
  • Element 4: At least one listener The rest of JMeter works for these elements.

4. JMeter working directory

JMeter’s working directory contains the following folders/files:

  • Bin: stores configuration files (such as log Settings and JVM Settings), startup files, startup Jar packages, and instance scripts
  • Docs: An offline help document to place the JMeter API
  • Extras: A JMeter helper that offers the possibility of taking commissions with Ant and Jenkins to build a performance test automation framework
  • Lib: JMeter components are stored as Jar packages in the lib/ext directory. If you want to extend JMeter components, Jar packages are stored in this directory. JMeter starts with Jar packages in this directory.
  • Printable_docs: An offline help file for JMeter that you can use to learn About JMeter;

5, summary

JMeter runs on the following logic:

  • The sampler simulates user requests; You can use the front manager to prepare the environment and data. A post-processor can be used to process the response data.
  • Control the run: use thread groups to set up the run scenario, use logical controllers to control the business (control the sampler);
  • Collect results: Use assertions to verify test results, and use listeners to collect and display test results;

JMeter also supports remote operation to compensate for insufficient load on a single machine.