Architecture

JMeter is a desktop application written in Java. It runs on any operating system that can launch JRE or JDK. JMeter has two modes of operation:

Important: You should always create tests in GUI mode but run real load tests in CLI mode. The GUI has a larger resource footprint and may ruin your test as GUI thread can hang virtual users will stop.

The Plug-In Architecture

In simple words, JMeter is a test engine that processes a tree of test elements. Almost every visible element (e.g. Sampler, Timer, Assertion or Listener) is a plug-in which implements a special Java interface so JMeter knows what is it and how to initialize it.

This means:

1. JMeter is extensible. The community maintains dozens of additional plug-ins. It’s possible to register the plugin for use with the JMeter Plugins Manager.
2. Protocol support is modular. HTTP, JDBC, JMS, LDAP, FTP, TCP, and SMTP are each provided by their own Sampler plug-in.
3. You can write custom plug-ins in Java/Kotlin or create custom scripts in Groovy via JSR223 elements.

┌──────────────────────────────────────────────┐
│                JMeter Engine                 │
│  ┌──────────┐  ┌──────────┐  ┌───────────┐   │
│  │ Samplers │  │  Timers  │  │ Listeners │   │
│  └──────────┘  └──────────┘  └───────────┘   │
│  ┌──────────────┐  ┌──────────────────────┐  │
│  │  Assertions  │  │  Pre/Post Processors │  │
│  └──────────────┘  └──────────────────────┘  │
└──────────────────────────────────────────────┘

Primary–Secondary (Distributed) Mode

If you need to create the load which cannot be conducted from a single machine due to lack of CPU, memory or network ports you can run JMeter in distributed mode. It assumes the following setup:

• A primary (client) node which sends test plan to slave machines and collects results from them.
• One or more secondary (server) nodes which produce the actual load and send interim test results back to primary.

        ┌────────┐
        │ Primary│  ← holds .jmx, starts test, collects results
        └───┬────┘
     ┌──────┼──────┐
     ▼      ▼      ▼
┌────────┐┌────────┐┌────────┐
│Scnd  1 ││Scnd  2 ││Scnd  3 │  ← generate HTTP/JDBC/… traffic
└────────┘└────────┘└────────┘

You can configure secondary nodes in user.properties file via remote_hosts setting. In this book, we omit end-to-end configuration of JMeter in distributed mode, but it is worth noting that JMeter can scale and produce significantly high load. The "How to Perform Distributed Testing in JMeter" article in our blog which highlights the most important configuration options and challenges with solutions.

Thread Model

Each virtual user in JMeter is a “normal” Java thread. A Thread Group defines how many virtual users to create, how fast they will arrive (all at once or gradually), and how many times each virtual user iterates executes Samplers in Test Plan. Normally, you can simulate several thousand virtual users from a mid-range modern laptop; the real number depends on several factors like:

• Nature of your test plan (number of Samplers, Pre/Post processors, assertions, etc.)
• CPU and memory of your machine
• JMeter configuration (including configuration of JVM)

If you’re looking for a general reference: Allocate roughly 1 MB of heap per HTTP virtual user for planning load generator memory.

Summary

• JMeter is a Java-based, plug-in based extendable test engine.
• Use GUI mode for creating your tests and non-GUI mode for execution.
• Distributed mode lets you use multiple machines for load test execution
• Each virtual user is a Java thread so the maximum number depends on available memory and CPU.

Now let’s proceed with JMeter installation.