Optimizing Druid Connection Pool: Practical Configurations and Tuning Guide

Introduction

Database connections consume a large portion of request latency, especially during traffic spikes or network reconnections. When SQL appears slow, the root cause is often an improperly configured connection pool rather than the query itself.

Key Considerations

When configuring Druid, focus on the following aspects:

Appropriate pool size

Idle‑connection handling

Network‑related timeout values

Efficient connection reuse

Druid version selection

Setting the Pool Size

The pool size should match the application’s QPS and average request response time (RT in ms). The basic formula is:

Connection count = QPS /(1000/RT) + N = QPS * RT / 1000 + N

Example: RT = 2 ms, QPS = 5 000 → 5 000 / (1000/2) = 10 connections. Add a safety margin N as needed.

Configuring Timeouts

connectTimeout – TCP connection establishment timeout maxWait – Maximum wait time for a connection from the pool socketTimeout – Timeout for waiting for a response after a request is sent

Recommendations:

connectTimeout should not be less than 1200 ms to tolerate network jitter during pool initialization.

socketTimeout should be at least 300 ms; set it according to the longest expected query time. Too short a value causes frequent timeouts, while too long is unnecessary because the database’s SQL‑killer will abort excessively long queries.

maxWait defaults to 800 ms (conservative). It can be reduced to ~300 ms for fast services, but never below 100 ms to avoid exhausting the pool during transient network issues.

Connection Keep‑Alive Settings

In typical production environments the request path is:

App → LVS → Proxy → DB

LVS keeps idle connections for 90 s, while the proxy retains them for 70‑85 s. Therefore, the application should set its own idle‑connection timeout to no more than 70 s to avoid receiving closed connections.

When keep‑alive is enabled, Druid will pre‑fill the pool to minIdle and periodically run keepAlive for connections that have been idle longer than minEvictableIdleTimeMillis. Abandoned connections detected by ExceptionSorter are removed and replaced automatically.

timeBetweenEvictionRunsMillis=10000
minEvictableIdleTimeMillis=44000
maxEvictableIdleTimeMillis=55000

Essential Druid Properties

<bean id="cartDataSource" class="com.alibaba.druid.pool.DruidDataSource">
    <property name="url" value="${cluster.jdbc.url}" />
    <property name="username" value="${cluster.jdbc.username}" />
    <property name="password" value="${cluster.jdbc.password}" />
    <property name="connectionInitSqls" value="set names utf8mb4" />
    <property name="initialSize" value="5" />
    <property name="maxActive" value="20" />
    <property name="minIdle" value="5" />
    <property name="maxWait" value="800" />
    <property name="connectTimeout" value="1200" />
    <property name="socketTimeout" value="3000" />
    <property name="validationQuery" value="SELECT 1" />
    <property name="validationQueryTimeout" value="1" />
    <property name="removeAbandoned" value="true" />
    <property name="logAbandoned" value="true" />
    <!-- Additional properties such as testWhileIdle, testOnBorrow, etc., can be added as needed -->
</bean>

Version Recommendation

Use the latest stable Druid version (1.1.16 or newer). Older versions may contain bugs that affect pool behavior.

<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>druid</artifactId>
    <version>1.0.27</version>
</dependency>

Conclusion

By calculating the pool size from QPS and RT, setting sensible timeout thresholds, enabling keep‑alive when appropriate, and using up‑to‑date Druid configurations, developers can avoid false‑slow SQL reports, reduce connection‑related errors, and achieve more stable performance under load.