Other Samplers

The FTP Request sends one FTP "retrieve file" or "upload file" request per sample. For a download the file can be stored on disk (Local File), kept in the response data, or both. Use it when the system under test exposes FTP as a real interface: a nightly catalogue export a partner downloads, or an import folder a supplier uploads to. It speaks plain FTP only; the element has no option for FTPS or SFTP.

In the 5.6.3 source each sample creates a new Apache Commons Net FTPClient, connects, logs in, switches to passive mode, transfers the file, logs out and disconnects. The component reference states that Latency is set to the time it takes to login; the source takes the latency mark right after the connection is established, before the login. In both readings, the elapsed time of the sample covers the whole connect, login, transfer and logout cycle, so an FTP sample measures a complete session, not just the transfer.

FTP Request Defaults (Add → Config Element → FTP Request Defaults) has the same server, port, file and mode fields and supplies them to every FTP Request in its scope that leaves them empty.

Source: FTP Request (Component Reference)

The official tutorial builds 4 users that fetch two files twice: (4 users) × (2 requests) × (2 loops) = 16 FTP requests. The Bookshelf version below is the same shape, aimed at a local FTP server that publishes the nightly catalogue export:

Source: Building an FTP Test Plan

The response code of a successful transfer is 200 (JMeter’s generic OK), and a refused transfer carries the FTP reply code and reply text (for example 550) as response code and message, so a Response Assertion on the code works as it does for HTTP. A connection failure is reported as 501, Could not connect, and an exception as 000.

The LDAP Request sends one of four operations to an LDAP server: Add, Modify, Search or Delete. Each operation can run as an inbuilt test or a user defined test:

Inbuilt tests are self-cleaning, which makes them a quick way to check that a directory accepts writes under load. User defined tests are the ones that resemble real traffic. Use the LDAP Request for simple, independent operations. When the traffic is a session (bind once, then several operations), use the LDAP Extended Request instead.

LDAP Request Defaults (Add → Config Element → LDAP Request Defaults) supplies server, port and DN to every LDAP Request in scope; the Login Config Element (Add → Config Element → Login Config Element) supplies user and password.

Source: LDAP Request (Component Reference)

The official tutorial runs the four inbuilt tests with 4 users and 4 loops: (4 users) × (4 requests) × (4 loops) = 64 LDAP requests. Against a local directory for the Bookshelf users (dc=bookshelf,dc=local):

Source: Building an LDAP Test Plan

The LDAP Extended Request is the full-featured LDAP sampler. It is harder to configure than the LDAP Request but much closer to a real LDAP session. Any LDAP request is part of a session, so a thread starts with a Thread bind, runs its operations on that connection, and ends with a Thread unbind. The available operations are:

Every operation has a Name. The others depend on the selected operation:

The selected operation is stored in the test property (bind, unbind, sbind, rename, add, delete, search, modify, compare). LDAP Extended Request Defaults (Add → Config Element → LDAP Extended Request Defaults) can pre-fill any of these fields; a value entered in a sampler overrides the default. When a value that a test needs is missing everywhere, the tutorial warns that the test fails in an unpredictable way.

Source: LDAP Extended Request (Component Reference)

The official tutorial adds the nine operations in order for 1 user and 1 loop: (1 user) × (9 requests) × (1 loop) = 9 LDAP requests. A realistic Bookshelf session keeps only the read path: bind as the service account, look the user up, check group membership and unbind.

Source: Building an Extended LDAP Test Plan

username comes from the users.csv CSV Data Set Config that the rest of the section uses (see Parameterization & Test Data).

The OS Process Sampler executes a command on the load generator machine. Any command that can be run from the command line can be run, and the return code can be validated. Typical uses: a setUp Thread Group that seeds the Bookshelf database with a script, a health check before the load starts, or driving a command-line client of the system under test when nothing else can speak its protocol.

The sampler deliberately does no parsing or quoting. The command and each parameter are passed as given, so the settings are not portable between operating systems, and shell built-ins (Windows DIR, the POSIX shell’s cd) must be passed to their command interpreter: Command CMD, Param 1 /C, Param 2 DIR, Param 3 the folder.

Source: OS Process Sampler (Component Reference)

In a setUp Thread Group (1 thread, 1 loop), Add → Sampler → OS Process Sampler: Command curl, parameters --silent, --fail, --retry, 10, --retry-connrefused, and the URL; Check Return Code ticked with expected code 0; Timeout 60000. If the API is still down after the retries, curl returns a non-zero code, the sample fails, and the Thread Group’s Action to be taken after a Sampler error can stop the test before the load starts.

Source: OS Process Sampler (Component Reference)

The curl options belong to curl itself, not to JMeter. The response code of the sample is the process’s return code; with Check Return Code the response message is OK or Unexpected return code. Expected [0]. Actual [n]. If the process cannot be started or is interrupted, the 5.6.3 source sets response code 500, which is why the documentation reserves that value.

The Java Request controls a Java class that implements org.apache.jmeter.protocol.java.sampler.JavaSamplerClient. By writing such a class you can put any Java client library (a proprietary protocol, a vendor SDK, a cache client) under load and still let JMeter supply threads, parameters and result collection. The Classname drop-down lists every implementation JMeter finds; two examples ship with it, JavaTest and SleepTest. JavaTest lets you set almost every field of the result, which is handy for checking assertions and listeners without a server.

The life cycle comes from the interface’s Javadoc. JMeter creates one instance of the class per thread. When the test starts it calls setupTest on each thread’s instance, then runTest once per iteration, and finally teardownTest. Parameters are read through a JavaSamplerContext, and getDefaultParameters declares the parameter names and default values the GUI shows. Extend AbstractJavaSamplerClient rather than implementing the interface directly: it provides default implementations, and JMeter only calls teardownTest when a subclass overrides it, which reduces memory use.

The parameters of the bundled examples:

Java Request Defaults (Add → Config Element → Java Request Defaults) sets default values for Java Requests in scope.

Source: Java Request (Component Reference)

The class below measures GET /api/books?query= with the JDK’s own HTTP client, standing in for any Java client library. It reads its parameters once in setupTest, times only the call in runTest, and reports the HTTP status:

Source: AbstractJavaSamplerClient (JMeter Javadoc)

Compile it against ApacheJMeter_core and ApacheJMeter_java 5.6.3 (both on Maven Central under org.apache.jmeter) with Java 11 or later (for java.net.http), package it as a jar and copy the jar to lib/ext. The default parameter values are expressions; the Java Request evaluates them per sample like any other field, so term follows the CSV data. The sampler block in the plan then looks like this:

Source: Java Request (Component Reference)

How the class is found. JMeter 5.6 started loading plugins through Java’s ServiceLoader instead of classpath scanning (PR 5885). In 5.6.3 the Java Request still does both: it loads JavaSamplerClient services and also scans the jars on the search path, and the source marks the scanning as a transition step towards ServiceLoader-only lookup. A jar built today should therefore also carry a service file, so it keeps working when the scanning goes:

containing the single line com.example.bookshelf.jmeter.BookSearchClient.

Worked numbers. With the canonical load profile (50 threads, 60 s ramp-up) and the section’s 3 s think time, a Java Request whose call takes 0.2 s cycles every 3.2 s per thread: 50 / 3.2 ≈ 15.6 samples per second at full load, exactly like the HTTP version of the same step. The Java Request adds no overhead of its own beyond the class’s code.

The JUnit Request runs an existing JUnit test method as a sampler, so a suite of functional tests can be put under load without rewriting it. It supports the standard JUnit 3 convention (classes extending TestCase) and, with Search for JUnit 4 annotations ticked, JUnit 4 annotations. The documentation does not mention JUnit 5 (Jupiter), and 5.6.3 bundles JUnit 4.13.2, so tests written for JUnit 5 only must be adapted or run through a Java Request instead.

Key differences from a normal JUnit runner:

The recognised JUnit 4 annotations are @Test (with its expected and timeout attributes), @Before, @After, @BeforeClass and @AfterClass.

Source: JUnit Request (Component Reference)

Package the compiled test classes as a jar, copy it to lib/junit, then Add → Sampler → JUnit Request: tick Search for JUnit 4 annotations, set Package Filter to com.example.bookshelf, pick com.example.bookshelf.smoke.BookSearchSmokeTest and the method searchReturnsOk. The setUp is public, as the documentation requires, and keeps no static state. Pass the URL as a system property with -Dbookshelf.url=... when JMeter starts.

Source: JUnit Request (Component Reference)

The documentation’s own guidelines for tests that run well under JMeter:

The sampler itself is cheap. The cost is the test code: a test that creates a new HTTP client in setUp creates one per sample, which is slower than production clients that reuse connections.

The Bolt Request runs Cypher queries against Neo4j over the Bolt protocol. It was added in JMeter 5.2; 5.5 added the database, access-mode and transaction-timeout options and the pool-size setting. Each request takes a connection from the pool of a Bolt Connection Configuration and returns it when the sample completes. The measured time is the full query execution: running the Cypher statement and consuming the results the database sends back.

For Neo4j itself (the property graph model, Cypher, drivers, transactions and clustering), see the Neo4j Reference, in particular Cypher fundamentals and Transactions and drivers. This section adds only what JMeter needs.

Bolt Connection Configuration (Add → Config Element → Bolt Connection Configuration):

Bolt Request (Add → Sampler → Bolt Request):

The documentation strongly advises query parameters, which let the database cache and reuse execution plans. Concatenating ${bookId} into the Cypher text produces a new query text per value and defeats that cache.

Source: Bolt Request (Component Reference)

Suppose Bookshelf keeps "readers also borrowed" links in a local Neo4j as (:Book)-[:ALSO_BORROWED]->(:Book). The request below reads five recommendations for the book the user is viewing:

Source: Bolt Connection Configuration (Component Reference)

$bookId is a Cypher parameter resolved by Neo4j; ${bookId} is a JMeter variable resolved by JMeter inside the JSON of Params. The two are not the same thing, and only the JMeter one is substituted before the query is sent.

Worked numbers for the pool. The 5.6.3 source creates one driver, with the configured pool, when the test starts, and every Bolt Request borrows from it. With 150 threads and the default pool of 100, at most 100 queries can be in flight, and up to 50 threads wait for a connection; that wait is inside the measured time. If a query takes 20 ms and think time is 3 s, each thread holds a connection less than 1 % of the time and 100 connections are plenty; the pool only matters for short think times or long queries. Size it as at least the number of threads that can run a Bolt Request at the same moment.

The Access Log Sampler reads a web server access log and turns each entry into an HTTP request, so a test can replay real traffic instead of a guessed mix. The access-log tutorial lists its benefits: real traffic data, a record of how usage changes over time, and session information. It also lists the cases where access logs are inappropriate:

A log that contains POST data can contain passwords in plain text, so the tutorial also suggests custom logging that keeps sensitive data out of the log.

The sampler understands the common log format:

The parser only looks at the quoted text containing an HTTP method (GET, PUT, POST, DELETE and so on). Everything else, including the response code, is ignored. Internally the sampler creates an HTTP sampler through a generator, sets its server, port and image parsing, asks the parser for one entry and calls the HTTP sampler. So each sample replays exactly one log line. The component reference still labels the element (Beta Code).

The parsers and filters differ in how threads share the log:

Source: Access Log Sampler (Component Reference)

Source: Access log sampler Step-by-step

Worked numbers. Take a one-hour Bookshelf log of 36,000 lines and a Thread Group of 10 threads, each with an iteration count large enough to reach the end of the log. With TCLogParser every thread replays the whole log, so the server receives 10 × 36,000 = 360,000 requests: ten copies of the same hour. With SharedTCLogParser the threads take turns, so the log is replayed once, 36,000 requests in total, at whatever speed 10 threads without think time can reach. Neither parser reproduces the timestamps of the log; add a timer if the original pacing matters. The behaviour at the end of the file is not described in the documentation, so set the iteration count from the line count rather than relying on it.

The Debug Sampler generates a sample whose response data lists the values of all JMeter variables, JMeter properties and system properties, each section sorted by name. It is the quickest way to see what a CSV Data Set, an extractor or a __P call really produced while a plan is being built: put it after the step under suspicion and look at the Response Data pane of View Results Tree.

Source: Debug Sampler (Component Reference)

After the login request of bookshelf-load.jmx, Add → Sampler → Debug Sampler named DEBUG after login, with only JMeter Variables ticked:

Source: Debug Sampler (Component Reference)

Run one thread and one iteration; the response data reads like this (values shortened, placeholders only):

If token is missing or holds the extractor’s default value, the problem is in the extractor, not in the next request. The neighbouring Debug PostProcessor does the same as a sub-sample of a chosen sampler and can also show the sampler’s properties; see Correlation & Extractors for the full debugging workflow.

The Flow Control Action is a sampler intended for use inside a conditional controller. Rather than generate a sample, it pauses, stops the selected target, or changes the loop flow. It was called Test Action before JMeter 5.0, and the older name still appears in old plans and in the .jmx class name, TestAction. JMeter 5.0 also added the loop actions Go to next iteration of Current Loop and Break Current Loop.

Typical uses:

The component reference lists the actions as Pause, Stop, Stop Now and Go to next loop iteration; the 5.6.3 GUI shows the six radio buttons above, and the numbers in parentheses are the stored values from the 5.6.3 source.

Stop stops the thread or test after any samples in progress complete. Stop Now stops the test without waiting and interrupts active samples. If some threads do not stop within 5 seconds, GUI mode shows a message, and CLI mode exits JMeter. That limit is the jmeterengine.threadstop.wait property, in milliseconds (default 5000).

Source: Flow Control Action (Component Reference)

Source: Flow Control Action (Component Reference)

TOKEN_NOT_FOUND is the default value given to the JSON Extractor for token in the login step (see Correlation & Extractors); the If Controller and its Interpret Condition as Variable Expression? option are covered in Logic Controllers & Transactions. Only the threads whose login failed stop; the others carry on, instead of the failed ones sending unauthenticated requests, each counted as an error, for the rest of the run.

The MongoDB Script sampler and its MongoDB Source Config element were deprecated in JMeter 3.0 (Bugzilla 58772). Since then they no longer appear in the menu: the default not_in_menu property in bin/jmeter.properties lists org.apache.jmeter.protocol.mongodb.sampler.MongoScriptSampler and org.apache.jmeter.protocol.mongodb.config.MongoSourceElement. The JMeter team advises not to use them. The changes.xml on master plans their removal in 6.0 (PR 6573), together with the bundled mongo-java-driver (2.14.3 in 5.6.3): plans that use them will no longer load, and the stated replacement is a JSR223 Sampler with the MongoDB Java driver of your choice.

The books still present this sampler as a normal element (Cookbook ch. 4; PTwJ ch. 7). Treat those recipes as history.

The sampler sends a script to MongoDB through com.mongodb.DB#eval, which takes a global write lock and so hurts the database’s performance. The documentation itself says it is better avoided for load testing and is more suitable for functional testing or test set-up in setUp and tearDown Thread Groups.

The MongoDB Source Config takes a Server Address List, the MongoDB Source variable name (unique across the plan), and driver options: Keep Trying, Maximum connections per host, Connection timeout, Maximum retry time, Maximum wait time (default 120,000 ms), Socket timeout, Socket keep alive, ThreadsAllowedToBlockForConnectionMultiplier (default 5) and the write-concern settings (Safe, Fsync, Wait for Journal, Wait for servers, Wait timeout, Continue on error). Each thread gets its own connection.

Source: MongoDB Script (DEPRECATED) (Component Reference)

The replacement that changes.xml names is a JSR223 Sampler with a MongoDB Java driver you install yourself. Copy the synchronous driver jars (mongodb-driver-sync, mongodb-driver-core and bson, all the same version) into lib, restart JMeter, and share one MongoClient per test through a property, created once in a setUp Thread Group:

Source: JSR223 Sampler (Component Reference) and MongoDB Java Sync Driver

The scripts follow the rules of Scripting with JSR223 & Groovy: no ${...} inside a cached script (values come from vars and props), one shared client because the MongoDB driver manages its own connection pool, and a MongoClient.close() in a tearDown Thread Group. The JSR223 Sampler times the whole script, so keep it to the database call.