JDBC Database Load Testing and Connection-Pool Considerations: Core Concepts and Mental Model

1. The practical problem: “database is slow” is not a workload definition

An API response can be slow because of application code, remote calls, connection-pool wait, SQL execution, lock waits, serialization, or generator/network effects. A direct JDBC test removes most application layers and asks a narrower question: how does this database/query/connection path behave when JMeter itself opens JDBC connections?

2. Mental model: JMeter pool → JDBC sampler → DB engine → evidence

flowchart TD
W[Threads / inputs / pacing] --> CC[JDBC Connection Configuration]
D[H2 driver in JMETER_HOME/lib] --> CC
CC --> P[JMeter DBCP connection pool]
P --> JR[JDBC Request]
JR -->|Prepared SQL + parameters| DB[H2 TCP database 127.0.0.1:9092]
DB --> RS[Rows / SQL errors]
RS --> A[Response/variable assertions]
JR --> J[JTL + jmeter.log]
DB --> S[INFORMATION_SCHEMA.SESSIONS]
DB --> Q[QUERY_STATISTICS]
G[Generator CPU / GC / sockets] --> V[Validity review]
J --> V
S --> V
Q --> V

Threads and data determine how many query opportunities JMeter creates. JDBC Connection Configuration resolves the driver/URL/user/pool policy and builds JMeter's client-side DBCP pool. JDBC Request borrows a connection, executes SQL, returns rows/errors, and records a sample. H2 independently exposes active sessions and query statistics. Generator CPU/GC/sockets are separate evidence. Nothing in this path measures an application's own web tier or its connection pool.

3. JMeter JDBC pool is not the application pool

JMeter creates its own JDBC connections. If the production application uses HikariCP, an application-server datasource, or an ORM-managed pool, those connections are not present in a direct JDBC JMeter plan.

Therefore “JMeter pool max=10” does not mean the application pool is 10, and “DB handles 10 JMeter connections” does not prove the application can handle 10 concurrent requests.

4. The surprising meaning of Max Number of Connections = 0

Current JMeter JDBC Connection Configuration documentation recommends 0 in most cases. Here, zero does not mean “no connections” or “unlimited shared pool.” It means each JMeter thread gets its own pool containing one connection, so connections are not shared between threads.

With 2 threads and baseline max=0, predict roughly two JMeter database sessions while both threads are active.

5. JDBC sampler latency has pool meaning

For JDBC Request, JMeter sets the sample's latency to the time taken to acquire a connection. Total elapsed includes connection acquisition plus query execution/result processing.

This makes a constrained shared pool diagnostically useful: rising latency with otherwise stable DB query time suggests client-side connection wait rather than database execution slowdown.

6. Driver state belongs to the JMeter JVM

JMeter does not bundle every vendor JDBC driver. The H2 JAR must be available on JMeter's runtime classpath—normally by copying h2-2.5.250.jar into JMETER_HOME/lib and restarting JMeter. The connection uses org.h2.Driver.

A “No suitable driver” or class-not-found error is generator/classpath state, not database saturation.

7. Credentials and least privilege

JDBC Connection Configuration can store a username/password in the test plan; its password field is not encrypted in JMX. The chapter therefore uses only fake lab credentials in the generated examples. In a real authorized environment, inject credentials through an approved secret mechanism and keep them out of source control/result artifacts.

The JMeter account receives SELECT on one synthetic table only. It cannot create/drop/update/delete that table.

8. Prepared parameters versus SQL string construction

Use Prepared Select Statement with ? placeholders and parameter values/types instead of concatenating arbitrary data into SQL. Prepared binding preserves type semantics and avoids SQL-injection mistakes caused by untrusted/string-interpolated inputs.

9. State to define before changing JDBC load

10. Non-destructive inspection first

Before JMeter load, use the local H2 Shell/admin account to check:

SELECT COUNT(*) AS ROWS FROM PUBLIC.CATALOG_ITEM;
SELECT MIN(ID), MAX(ID), COUNT(DISTINCT CATEGORY) FROM PUBLIC.CATALOG_ITEM;
SELECT GRANTEE, RIGHTS, TABLE_SCHEMA, TABLE_NAME
FROM INFORMATION_SCHEMA.RIGHTS
WHERE GRANTEE='JMETER_READ';
SELECT USER_NAME, SESSION_STATE, COUNT(*) AS SESSIONS
FROM INFORMATION_SCHEMA.SESSIONS
GROUP BY USER_NAME, SESSION_STATE;

Then connect as JMETER_READ and prove a SELECT succeeds. Do not “prove” read-only access by executing a destructive statement against any non-disposable database.

11. Database telemetry and visibility

H2 INFORMATION_SCHEMA.SESSIONS shows session IDs, users, executing statement, state, and blocker information. Only ADMIN users can see all sessions; ordinary users see only their own. This is why telemetry inspection uses a separate local admin shell, while JMeter stays least-privilege.

With SET QUERY_STATISTICS TRUE, INFORMATION_SCHEMA.QUERY_STATISTICS records execution counts and min/max/cumulative/average query time. This is target evidence, not a substitute for JTL.

12. Configured versus achieved database load

Configured load is threads/loops/timers/query opportunities. Achieved load is how many valid JDBC samples actually execute per unit time. A small JMeter pool, slow connection acquisition, query errors, generator CPU pressure, or DB saturation can reduce achieved load even when thread count is unchanged.

13. DevOps connection

Direct database load testing belongs in a production performance program as a controlled diagnostic/capacity experiment with explicit authorization, schema/data ownership, pool settings, driver version, SQL set, telemetry, and cleanup. It is not a shortcut around application-level testing.

Knowledge check

Official references and version notes

• JMeter Component Reference — JDBC Connection Configuration — pool variable, max connections, max wait, validation, auto-commit, isolation, driver class, and credential storage.
• JMeter Component Reference — JDBC Request — prepared/select query types, parameters, result variables, query timeout, and connection-acquisition latency.
• JMeter Getting Started — Java requirements and GUI-versus-CLI execution.
• JMeter Dashboard Report — result-file requirements and post-run reporting.
• JMeter Best Practices — non-GUI load execution and generator validity.
• Apache JMeter downloads — current stable release and Java requirement.
• H2 Database Engine — current release and JDBC capabilities.
• H2 Quickstart — driver class and JDBC URL basics.
• H2 Tutorial — server mode, JDBC access, Shell, and Java tooling.
• H2 System Tables — SESSIONS and QUERY_STATISTICS telemetry.
• H2 Commands — CREATE USER, GRANT SELECT, SET QUERY_STATISTICS, and read-only SQL semantics.