Everything JMeter measures starts with a sampler, so we begin by understanding exactly what that word means.

The sampler in one sentence

A sampler is the part of a JMeter test plan that actually performs an action against the system under test and records how long the action took and whether it succeeded. Every other element, whether it counts users, waits, checks answers or draws graphs, exists to support the samplers. If a test plan were a play, the samplers would be the actors who do the real things on stage.

What a protocol is

A protocol is an agreed set of rules for how two computers talk. The web uses one protocol, file transfer servers use another, databases use their own, and message brokers use yet another. Each protocol defines how a conversation begins, what a request looks like, what an answer looks like and how the conversation ends. A tool that wants to test a system must follow the rules of the protocol that system speaks.

Why testing at the right protocol matters

Modern systems are chains. A web page calls a service, the service calls a database, the database is backed up through a file transfer, and a notification goes out through a queue and then through mail. A slowdown can hide at any link. Testing only through the web front may show that the whole chain is slow without revealing which link is weak. Testing a link directly, using its own protocol, isolates it and tells you its true capacity.

A short vocabulary now will make every later chapter easier to follow.

Before diving into details, a single map shows which sampler serves which kind of system.

flowchart LR
  P[JMeter Test Plan] --> W[HTTP Sampler]
  P --> D[JDBC Sampler]
  P --> F[FTP Sampler]
  P --> L[LDAP Samplers]
  P --> T[TCP Sampler]
  P --> M[JMS Samplers]
  P --> S[SMTP Sampler]
  P --> J[Java and Scripting Samplers]
  W --> A[Web Tier]
  D --> B[Database]
  F --> C[File Server]
  L --> E[Directory Server]
  T --> G[Custom Service]
  M --> H[Message Broker]
  S --> I[Mail Server]
        

The details differ, but every sampler follows the same inner rhythm.

The common sequence

When a virtual user reaches a sampler, JMeter first resolves any property or variable references in the sampler’s fields, so a server name or query can change per user. It then prepares a result object and starts a timer. The sampler opens or borrows a connection, sends the request in the protocol’s format, waits for the answer, reads it, and stops the timer. Finally it marks the result as success or failure, stores any response data and hands the result to assertions, post-processors and listeners.

What the timer actually measures

The elapsed time normally covers sending the request and receiving the response. Whether connection setup is included depends on the sampler and its settings. A sampler that opens a new connection every time includes that cost, while one that reuses a pooled connection does not. This is a very common source of confusion when comparing numbers from different tests, so always know how your sampler handles connections.

Success is protocol-specific

On the web, a status code tells you whether the call worked. Other protocols have their own ways of signalling failure: a database returns an error condition, a directory returns a result code, a socket may simply time out. JMeter translates each of these into its common result format, but the meaning of the response code field varies. Add assertions to confirm business correctness, because a technically successful call can still return wrong or empty data.

sequenceDiagram
  participant V as Virtual User
  participant S as Sampler
  participant C as Connection or Pool
  participant X as Target System
  V->>S: Reach sampler in plan
  S->>S: Resolve variables and properties
  S->>C: Get connection
  C->>X: Send protocol request
  X-->>C: Protocol response
  C-->>S: Return data
  S->>S: Stop timer and set success flag
  S-->>V: Result to assertions and listeners
        

File transfer is old but still everywhere, from nightly batch drops to partner integrations.

What it does

The FTP sampler connects to a file transfer server, logs in and either downloads a named remote file or uploads a local one. It records how long the transfer took and, for downloads, can keep the received content so assertions can check it. A companion config element lets you set the server, port and credentials once instead of repeating them in every request.

Settings that matter

What a good FTP test looks like

Use realistic file sizes, because transfer time depends heavily on size and a tiny test file hides bandwidth limits. Use a pool of different filenames or accounts where the real system would, so that caching does not flatter the results. Think carefully about the generator’s own network link: a few hundred users each downloading large files can saturate the generator long before the server struggles.

The database is often the real bottleneck, and this sampler lets you test it directly.

Two elements work together

The JDBC sampler never works alone. First you add a connection configuration element that holds the database address, driver class, credentials, pool size and a short validation query. You give this configuration a name, called the pool name. Then each JDBC request refers to that name so it knows which pool to use. This separation lets many samplers share one pool, exactly as real applications share connections.

The driver jar

JMeter cannot speak to a particular database until you place that vendor’s driver jar into its library folder and restart the tool. This is the number one reason first-time users see class-not-found errors. Remember that every load generator and every remote worker needs the same jar.

Types of statements

Reading what the database returns

A select statement can return thousands of rows, and what the sampler does with them affects both memory and your conclusions. It can count the rows without keeping them, store each column into numbered variables for later steps, or keep the whole result as an object. Counting is the lightest option and is usually enough for load tests. Keeping every row for every virtual user can quickly consume memory on the generator, and then the generator, not the database, becomes the slow part. Choose the lightest option that still lets your assertions prove the answer was right.

Timeouts deserve equal care. A query timeout stops a runaway statement from blocking a virtual user forever, and its value should reflect what your real application tolerates. Too short and healthy queries fail; too long and one stuck statement hides behind an average that looks acceptable.

Pool sizing is the hidden variable

If the pool holds ten connections and one hundred virtual users all want the database, ninety of them will wait. That waiting is real queueing, and it shows up as longer elapsed time or timeouts. This may be the exact behaviour you want to study, but it must be deliberate. Match the pool size to what the real application uses, or you are testing your own configuration rather than the database.

Directory servers answer the question “who is this person and what are they allowed to do” for countless systems.

What a directory server is

A directory server stores information about people, groups, devices and permissions in a tree-like structure, and is the backbone of corporate login. When an employee signs in to an internal tool, there is a good chance a directory lookup happens behind the scenes. Because every login in a company can touch it, its speed matters enormously.

The two samplers

The basic LDAP sampler covers everyday operations: binding which means authenticating, searching, adding entries, modifying entries, deleting entries and comparing values. The extended sampler covers special operations such as password changes and upgrading a connection to a secure one. Matching defaults elements store the common server details so each request stays short.

Search scope and filters

A directory search has three ideas worth knowing. The base is the branch of the tree where the search starts. The scope says how deep to look: only that entry, its direct children, or the whole subtree below it. The filter says what to match. A broad subtree search with a loose filter can force the server to examine a huge number of entries, while a narrow base with an indexed filter answers in a fraction of the time. Test the searches your applications really run, because a single badly designed search can dominate the load of the whole directory.

Designing a realistic directory test

Real traffic is mostly binds and searches with a small number of changes. A test that is half writes will not represent daily life. Vary the search filters, because a directory can answer a repeated search from cache much faster than a new one. Also think about connection behaviour: opening and closing a connection for every operation costs far more than reusing one, so mirror what your applications do.

When no ready-made sampler exists for a protocol, the TCP sampler lets you speak to the service at the lowest practical level.

What TCP is

TCP is the basic delivery layer beneath most internet protocols. It provides a reliable stream of bytes between two machines. Web, mail, file transfer and databases all sit on top of it. The TCP sampler skips the higher-level rules and simply opens a socket, sends the text or bytes you provide and reads what comes back.

Client implementations

The sampler uses a pluggable client class that decides how messages are framed. A plain text client sends your text and reads until a line ending or a timeout. A binary client lets you supply hexadecimal data. A length-prefixed client handles protocols where each message begins with a number saying how long it is. Choosing the client that matches your protocol’s framing is the single most important decision.

Common pitfalls with raw sockets

Raw sockets give you power and take away safety nets. If the response has no clear end marker and the client waits for one, every sample will run until the read timeout and the report will show a wall of identical slow results. If the protocol expects a greeting or a login handshake before the first real message, skipping it produces confusing errors. If the server closes idle connections, a reused socket will fail on the next sample. Each of these looks like poor server performance, yet each is really a mismatch between your test and the protocol’s rules.

A good habit is to capture a real conversation with a network analysis tool once, read it carefully and copy the exact message order and framing into your test. That small investment removes most guesswork.

When to choose it

Use the TCP sampler for in-house protocols, older systems, simple text services and devices such as payment terminals or sensors. It is also a handy way to check that a port is reachable and responsive under load. For anything more complicated, such as long multi-step binary conversations, a scripting sampler or a purpose-built plugin is often easier to maintain.

Messaging systems decouple senders from receivers, and they need their own style of test.

Why messaging is different

In a web request, the caller waits for an answer. In messaging, a sender drops a message at a broker and carries on; some other program picks it up later. This asynchronous style absorbs bursts and lets systems fail independently, but it makes performance harder to define. You care about how fast messages can be accepted, how fast they can be consumed and how long they wait in between.

Three samplers, three roles

Topics versus queues

A queue delivers each message to exactly one consumer, which suits work distribution. A topic delivers each message to every subscriber, which suits broadcasts and notifications. The behaviour under load differs: queues can build a backlog when consumers are slow, while topics multiply delivery work by the number of subscribers. Choose the one your real system uses.

Delivery guarantees change the numbers

Brokers let you trade speed for safety. A persistent message is written to disk before the broker confirms it, which protects against a crash but takes longer. A non-persistent message stays in memory and is much quicker, but can be lost. Acknowledgement modes and transactions add further layers of confirmation. If production uses persistent, acknowledged delivery and your test uses the fast settings, your results will promise a speed that production can never reach. Always copy the delivery settings of the real system.

The shape of the message matters too. A small text message and a large object with many fields stress serialisation, network and storage very differently. Use payload sizes drawn from real traffic, including the occasional large message, because the rare large message often decides the worst-case delay.

What you need to set it up

These samplers use a standard naming service to find the broker, so you provide the context factory class, the provider address, the connection factory name and the destination name, plus credentials if needed. Like databases, brokers require their client jar files to be placed in JMeter’s library folder before anything works.

flowchart LR
  P[JMS Publisher Samplers] --> B[Message Broker]
  B --> Q[Queue or Topic]
  Q --> S[JMS Subscriber Samplers]
  Q --> R[Real Consumer Application]
  R --> Y[Reply Queue]
  Y --> PP[JMS Point-to-Point Sampler]
        

Email remains the workhorse of notifications, receipts and password resets, so its capacity deserves testing.

The SMTP sampler

This sampler sends an email through an outgoing mail server. You supply the server address and port, the sender and recipients, the subject and the body, and optionally attachments, custom headers, authentication details and a secure connection mode. It can also send a ready-made message file. The measured time covers the conversation with the mail server, not the time for the message to reach the recipient’s inbox, which depends on many other systems.

The Mail Reader sampler

The reader connects to a mailbox using one of the standard retrieval protocols and fetches a chosen number of messages, optionally deleting them afterward. It is useful for testing mailbox servers and for closing the loop in workflows, such as confirming that a notification actually arrived after a test action.

Sometimes the cleanest way to speak to a system is to reuse the Java library its own developers provide.

Java Request

This sampler runs a class that you write by following a simple contract: set up before the test, run once per sample, and clean up afterwards. Inside the run step, your code can call any library, open any kind of connection and decide for itself what counts as success. Parameters from the test plan are passed in so the same class can behave differently per test. Your compiled class is packaged as a jar file and placed in the extensions folder.

JUnit Request

Many teams already have automated tests written with a popular Java testing framework. The JUnit sampler can run those test methods as samples, reusing existing work. It lets you run one test class, choose a method and optionally call setup and teardown steps. This is a fast way to turn functional checks into rough performance checks, though real load tests often need more careful control than functional tests provide.

When nothing built-in fits, a scripting sampler lets you write the missing behaviour yourself, inside the plan.

JSR223 Sampler

This sampler runs a script in a supported scripting language, with Groovy being the common recommendation. The script can read and write variables, call libraries available on the classpath, build any request it likes and mark the result as passed or failed. It is the most flexible element in JMeter, which is both its strength and its danger.

Why JSR223 is preferred over BeanShell

The older BeanShell sampler does similar things but interprets scripts less efficiently and is no longer the recommended choice. The JSR223 family can compile a script once and cache it, so thousands of virtual users do not pay compile cost on every iteration. This option, usually called caching compiled scripts, is essential for performance in heavy tests and should be switched on whenever it is available.

Using scripts safely

Several smaller samplers solve narrower problems, and knowing they exist saves a lot of custom work.

The built-in list is only the beginning; a large ecosystem of add-ons covers newer protocols.

The plugin manager

Most community extensions are installed through a plugin manager, a small tool that lists available add-ons and installs them with their dependencies. Plugins can add new samplers, timers, thread groups and listeners. Because they are produced outside the core project, quality, maintenance and licensing vary, so treat them as you would any dependency.

Protocols often added by plugins

A short decision table turns this menu of options into a confident choice.

Three guiding principles

First, test at the layer where the risk lives. If the worry is a slow query, a database sampler gives a cleaner answer than a web test that also includes rendering and network hops. Second, prefer the dedicated element to a script, because dedicated elements are documented, optimised and understood by colleagues. Third, keep the chain of evidence: measure each layer separately and also measure the whole chain, so you can explain both the total and its parts.

Most protocol-level surprises come from how connections are opened, shared and closed.

Per-user versus shared connections

Some samplers keep one connection per virtual user, such as a reused socket. Others share a pool, such as the database configuration. A shared pool couples users together: when the pool is exhausted, everyone waits. A per-user connection isolates users but multiplies the number of open connections on the server. Neither is better in general; the right model is the one your real applications use.

Warm-up and cold starts

The first requests on a new connection often run slower because caches are empty, connections are being established and servers are compiling code. Short tests can mistake this warm-up for normal behaviour. Allow time before you start counting, and run long enough that the system reaches a steady state.

Setup and teardown

Many protocol tests need preparation, such as creating accounts, queues or tables, and cleanup afterwards. A dedicated setup thread group runs before the main load and a teardown group runs after it. Using them keeps preparation time out of the measured results and leaves the environment tidy for the next run.

flowchart TD
  A[Setup thread group: create data and queues] --> B[Main thread groups: protocol load]
  B --> C[Teardown thread group: clean up]
  B --> D[Connections opened, reused or pooled]
  D --> E[Steady state measurement]
  E --> F[Results file and report]
        

The supporting elements work with every sampler, but each protocol needs its own thinking.

Assertions confirm business correctness

A response arriving quickly is worthless if its content is wrong. For database samplers, assert on the number of rows or on a particular value. For directory samplers, assert on the result code and the presence of an expected entry. For messaging, assert that a reply carries the right identifier. For file transfers, assert on size or a checksum. In each case the assertion turns a mere reply into proof of correct behaviour.

Extractors pass state forward

Protocol tests often depend on earlier steps: an order identifier produced by a database insert, a message identifier needed to match a reply, or a session value from a directory bind. Extractors, including those that read database result variables, carry such values to later samplers. Without them every virtual user acts blindly.

Timers shape realistic pacing

Real systems do not receive back-to-back requests from the same client. Timers add think time or control the overall rate. Some protocols, such as messaging, are better driven by a target rate than by a number of users, so a throughput-shaping approach may represent reality more closely than a plain thread count.

Test data keeps results honest

Feeding each user different usernames, queries, filenames or message bodies prevents caches from distorting results. A data-file element reads values from a file and gives each thread its own row. Keep these files outside the plan and make sure every generator has its own copy.

JMeter’s numbers show symptoms; the target system’s own metrics reveal causes.

Put both sides on one screen

When JMeter’s response times are streamed to a dashboard next to these server graphs, patterns become visible: a spike in elapsed time that lines up with a spike in lock waits points straight at the cause. Without server-side data you are forced to guess.

Protocol tests have extra dependencies, which makes the move from desktop to server worth planning.

Build and debug in the GUI

The graphical interface is the right place to configure connections, try single requests and read raw responses with detailed listeners. A one-user run with a debug sampler quickly shows whether the driver, credentials, addresses and extractors all work.

Measure from the command line

Real load runs belong in non-GUI mode, with only a lightweight results writer. For protocol samplers this matters even more, because responses such as large database result sets or downloaded files can use a great deal of memory if a listener keeps them.

Dependencies must travel with the plan

Protocol samplers touch the most sensitive systems a company owns, so security thinking is part of the design.

These patterns appear again and again in well-run protocol testing.

These mistakes look harmless and quietly ruin results.

Testing below the web layer brings real benefits and real costs.

A working order of operations helps you avoid the common stumbles.

Stories show how these samplers solve everyday problems.

The driver jar is almost certainly missing from JMeter’s library folder, or JMeter was not restarted after you added it. Remember that every generator and worker needs the same jar.

Yes. A single plan can call a web service, then query the database to verify the result, then check a queue. All samples land in the same results file and report, labelled by name.

Common causes are repeating the same query with the same parameters so that caches answer, using a tiny data set, or running against an empty test database. Use varied parameters and production-like data volumes.

JSR223 with a compiled-script cache is the recommended choice for performance and long-term support. BeanShell remains for older plans but is not the preferred option for new work.

Use request-and-reply sampling, or place a timestamp in each message and compare it when a consumer receives it. Also watch queue depth and message age on the broker.

It can talk to any socket service, but you must handle framing and message format yourself. For protocols with complex binary conversations, a plugin or a custom client is usually easier to maintain.

Typical reasons are missing jars or plugins, absent data files, blocked network ports and different JMeter or Java versions. Package the environment so it is identical everywhere.

Match what your real application uses. A smaller pool tests queueing for connections; a larger pool tests the database itself. Be clear which of these you intend to measure.

Yes, but each worker runs the full plan and needs its own jars, data files and network access. Thread counts apply per worker, so divide your target accordingly.

Some have been deprecated or removed in recent versions. Check the element list and the documentation of your installed release before designing a plan around an older sampler.

No. Use an isolated copy with disposable data and a reliable cleanup step, and confirm with the data owners before every run.

Check whether a built-in or maintained plugin sampler exists. If not, send one request by hand with the TCP sampler or a short script, read the raw reply and build up from there.

JMeter is far more than a web tester. Its family of protocol samplers lets you speak directly to databases, file servers, directories, message brokers, mail servers, raw sockets and custom code, all inside one plan and one reporting framework. The skill lies in testing the right layer in the language it understands, supplying realistic data and connection behaviour, preparing drivers and dependencies on every machine, and watching the target’s own metrics beside JMeter’s numbers. Used well, protocol samplers turn vague complaints about slowness into precise, explainable findings.