Beyond HTTP: Other Sampler Types
While the HTTP Request sampler dominates most modern test plans, JMeter was designed from the start as a protocol-agnostic load testing tool, and its sampler palette includes JDBC Request for databases, FTP Request for file transfer servers, TCP Sampler for raw socket protocols, plus JMS, SMTP, LDAP, and others. Each sampler type follows the same pattern: it is preceded by a connection or configuration element that establishes a reusable pool or connection, and the sampler itself issues one discrete operation per execution, exactly like the HTTP Request sampler issues one call, but the protocol details differ entirely.
Cricket analogy: Just as a cricket coaching academy trains players across formats, Test, ODI, and T20, each with different rules but the same underlying athlete, JMeter applies the same sampler-and-config pattern across totally different protocols.
JDBC Request Sampler
-- JDBC Connection Configuration:
-- Variable Name: dbPool
-- Database URL: jdbc:mysql://db.internal:3306/orders
-- JDBC Driver class: com.mysql.cj.jdbc.Driver
-- Max Number of Connections: 50
-- JDBC Request (Query Type: Select Statement):
SELECT status, total_amount FROM orders WHERE order_id = ?
-- Parameter values: ${orderId}
-- Parameter types: INTEGERThe JDBC Request sampler needs a JDBC Connection Configuration element first, which defines a Variable Name (referenced by the sampler), the Database URL, the JDBC Driver class (its JAR must be dropped into JMeter's /lib directory beforehand), and pool sizing options like Max Number of Connections. The sampler itself specifies a Query Type, Select Statement, Update Statement, Callable Statement, and so on, and the actual SQL, with '?' placeholders bound to Parameter values and Parameter types fields for prepared-statement style parameterization, which is both safer and more representative of how a real application talks to its database than string-concatenating values into the query.
Cricket analogy: Prepared-statement parameter binding is like a bowler practicing the exact same delivery mechanics while the batsman on strike changes, the query 'action' stays fixed while only the specific data (parameter) plugged in varies each time.
FTP Request Sampler
The FTP Request sampler tests file transfer performance against an FTP server, configured with Server Name, Port, Remote File (the path on the server), Local File (where to save a downloaded file or where to read an uploaded one from), and a Get(RETR) vs Put(STORE) toggle for direction. A binary-mode checkbox controls whether the transfer is treated as raw binary data or ASCII text, which matters for correctness with non-text files like images or archives. It's a specialized sampler used far less often than HTTP, but essential when the system under test genuinely relies on FTP for bulk file exchange, such as batch data ingestion pipelines or legacy enterprise integrations.
Cricket analogy: Choosing Get(RETR) versus Put(STORE) is like choosing whether a fielder is retrieving the ball from the boundary or throwing it back in, same physical exchange, opposite direction of travel.
Use the FTP Request sampler's binary-mode checkbox whenever transferring non-text files (images, archives, binary data dumps); leaving it in ASCII mode can silently corrupt such files during transfer.
TCP Sampler
The TCP Sampler opens a raw socket connection and sends/receives data exactly as specified, making it the right tool for testing custom or proprietary protocols that don't fit HTTP, FTP, or JDBC, such as IoT device telemetry, financial trading protocols, or internal microservice binary protocols. The ClassName field selects the TCPClient implementation, TCPClientImpl for plain text with newline-delimited messages, LengthPrefixedBinaryTCPClientImpl for binary protocols that prefix each message with its length, or a custom class implementing the TCPClient interface for anything more specialized. 'Re-use connection' keeps the socket open across sampler executions within a thread, mirroring how a persistent connection-based protocol actually behaves rather than reconnecting on every message.
Cricket analogy: Re-use connection is like a bowler continuing to bowl from the same end over after over without walking back to reset the field placement each time, maintaining the same setup across deliveries.
JDBC Connection Configuration pool sizing (Max Number of Connections) must be set to reflect realistic application behavior, not just the JMeter thread count; an undersized pool creates artificial contention and skews latency results in ways that don't reflect how the real application under test actually connects to its database.
- JMeter's sampler palette is protocol-agnostic, covering JDBC, FTP, TCP, JMS, SMTP, LDAP, and more beyond HTTP.
- JDBC Request requires a preceding JDBC Connection Configuration element defining the pool, driver, and URL.
- JDBC parameter binding with '?' placeholders is safer and more realistic than string-concatenated SQL.
- FTP Request sampler tests Get(RETR)/Put(STORE) file transfers, with a binary-mode toggle for non-text files.
- TCP Sampler opens raw sockets for custom/proprietary protocols, selecting a ClassName implementation to match the wire format.
- 'Re-use connection' in the TCP Sampler mirrors persistent-connection protocol behavior instead of reconnecting per message.
- Connection pool sizing must reflect realistic application behavior, not just match thread count, to avoid skewed results.
Practice what you learned
1. What must precede a JDBC Request sampler in the test plan?
2. Why is parameter binding with '?' placeholders preferred over string-concatenating values into a JDBC query?
3. What does the binary-mode checkbox in the FTP Request sampler control?
4. In the TCP Sampler, what does 'Re-use connection' do?
5. Why should JDBC Max Number of Connections not simply be set equal to the total JMeter thread count without further thought?
Was this page helpful?
You May Also Like
HTTP Request Sampler
The core JMeter element for sending HTTP/HTTPS requests to a server, covering method, path, parameters, body data, and implementation settings.
Parameterizing Requests with CSV Data
Use the CSV Data Set Config element to drive requests with varied, realistic test data instead of hardcoded values, avoiding caching and duplicate-key artifacts.
Correlation: Extracting Values with Extractors
Capture dynamic values like session tokens, CSRF tokens, and IDs from server responses and replay them in later requests using JMeter's extractor elements.