Project

spring-boot-default-tuning-lab

Purpose:

Benchmark Spring Boot default configuration under high concurrency to observe saturation behavior.

Environment

• Spring Boot
• PostgreSQL
• HikariCP (maxPoolSize=10)
• Embedded Tomcat (maxThreads=200)
• JMeter load test
• 10-minute steady state

Test Scenario

Observed Log Pattern

HikariPool-1 - Connection is not available,
request timed out after 30000ms
(total=10, active=10, idle=0, waiting=170+)

Interpretation:

• All connections occupied
• Threads queued
• 30-second timeout
• Request failure

Log scale

From 50 to 200 threads, latency grows proportionally, indicating increasing resource contention.
At 300 threads, error rate spikes to 42.93%, marking the connection pool saturation point.
The log-scale charts clearly show a capacity ceiling rather than gradual degradation.

Root Cause

Connection pool starvation.

Tomcat threads (200+)
vs
Database connections (10)

Concurrency exceeded available DB capacity.

Behavior Model

Under 300 users:

1. Connection pool saturates
2. Waiting queue grows
3. Latency spikes
4. Timeouts occur
5. Error rate increases

This represents a classic back-pressure failure pattern.

Key Insight

The default configuration does not implement adaptive back-pressure.

It assumes workload balance.

When concurrency increases without a commensurate increase in DB capacity, the system collapses rather than degrading smoothly.

Engineering Takeaway

To prevent this:

• Align thread pool and connection pool sizes
• Monitor pending connection metrics
• Set realistic timeouts
• Design for controlled saturation

Strategic Impact

This article positions you as:

• Performance engineer
• Not framework critic
• Not benchmark clickbait
• System-level thinker

Diagram — Thread vs Pool Mismatch

300 Concurrent Requests
            |
            v
+-----------------------+
|     Tomcat Threads    |
|        (200)          |
+-----------------------+
            |
            v
+-----------------------+
|   Hikari Connections  |
|         (10)          |
+-----------------------+
            |
            v
       PostgreSQL
When request threads greatly exceed available DB connections, connection pool starvation occurs.