The journey to solve response delays occurring right after deployment (feat. JVM warm-up)

When requests surged right after deployment, DB Connection Timeout and initial response delays kept recurring, and at first this was seen as a HikariCP configuration issue, so connectionTimeout, maximumPoolSize, and minimumIdle were adjusted. connectionTimeout was set to 10 seconds, maximumPoolSize was increased from 30 to 50, and minimumIdle was also set, but the symptom did not disappear.

Even after increasing the number of connections, right after deployment the pool always ended up being used up to its upper limit, while once things stabilized, far fewer connections were enough to handle the load. To reduce initial traffic, blue-green deployment was applied instead of a rolling update, gradually routing traffic in 20% increments every 30 seconds, but this was not a fundamental solution either.

The clue to the problem came from Actuator / Grafana metrics. Right after deployment, Connection usage time, normally under 5ms, increased to around 1–1.5 seconds, and Connection acquire time, normally under 1ms, also spiked to as much as 5–10 seconds, yet the database query response time did not change.

In other words, after a connection was acquired, heavy work inside the application itself was taking longer. After also confirming increased CPU usage and Young GC, the cause was ultimately redefined not as the DB but as the initial JVM receiving real traffic before it was sufficiently warmed up, and the issue was resolved by applying JVM warm-up to address the performance degradation right after deployment.