Analyzing the Cost of Establishing MySQL Database Connections in Java Applications

The author explores why creating database connections in long‑running applications can be costly, aiming to quantify the latency involved and illustrate the benefits of connection pooling.

The analysis focuses on MySQL because its protocol is open, allowing a detailed examination of the network, memory, and CPU resources consumed during connection establishment in a Java web application.

First, a minimal Java snippet is used to open a connection:

Class.forName("com.mysql.jdbc.Driver");

String name = "shine_user";
String password = "123";
String url = "jdbc:mysql://172.16.100.131:3306/clever_mg_test";
Connection conn = DriverManager.getConnection(url, name, password);
// program ends, connection is forcibly closed

Wireshark is then employed to capture the entire handshake process, revealing that MySQL communicates over a binary TCP protocol.

The connection establishment consists of three main steps:

Step 1: TCP three‑way handshake.

Step 2: Server sends a handshake packet; client responds.

Step 3: Client sends an authentication packet; upon success the server replies with OK and the session is ready for commands.

After successful authentication the client configures session variables (character set, autocommit, etc.) through several additional round‑trips. In the initial test the program terminates without calling Connection.close() , causing the TCP connection to be aborted with an RST packet.

Measuring the time from the start of the TCP handshake to the forced termination (excluding the final RST) yields:

10.416042 - 10.190799 = 0.225243s = 225.243ms

When the connection is closed properly with conn.close() , the measured latency drops to:

747.284311 - 747.100954 = 0.183357s = 183.357ms

Even in this minimal example, establishing a single MySQL connection consumes roughly 180‑225 ms, a figure that can vary with network conditions, server performance, and code efficiency.

Extrapolating to a site with 20 000 daily active users, each issuing five requests (100 000 requests per day), and assuming a conservative 150 ms per connection, the total time spent merely establishing connections would be:

100000 * 150ms = 15000000ms = 15000s = 250min ≈ 4.17h

This demonstrates why a connection pool is indispensable; otherwise a single day could waste several hours on connection overhead alone. As traffic grows, additional strategies such as caching, SQL statement pre‑compilation, and load balancing become necessary.

In summary, database connections are inherently expensive, and applications should avoid creating them repeatedly by leveraging pooling and related performance‑optimisation techniques.