[Refactor] 서버 튜닝 환경 반영

[taek2222]

📝 개요

아래 Todo 내용의 설정을 확인한 후 아래 요소를 적용한다.

✅ 할 일

• Tomcat 스레드 수
• DB 커넥션
• DB 드라이버
• Hickari

[coderabbitai]

Coding Plan

Approach

Configure server tuning parameters for Tomcat thread pools, HikariCP database connection pooling, and database driver settings to optimize application performance for both development and production environments.

Observations

FestaBook is a Spring Boot 3 application using MySQL database with embedded Tomcat and HikariCP (default connection pool). The project follows a profile-based configuration strategy with YAML files, where deployment scripts automatically activate either dev or prod profiles based on the AWS deployment group. Currently, the application relies entirely on Spring Boot defaults with no explicit tuning parameters configured. Monitoring is enabled via Prometheus metrics, which will allow tracking the effectiveness of these tuning changes.

Assumptions

Assumption 1: Target pool sizes and thread counts

Options Considered:

• Conservative baseline values suitable for moderate traffic (~100-500 concurrent users)
• Aggressive values for high-traffic scenarios (1000+ concurrent users)
• Minimal values matching current defaults

Chosen Option: Conservative baseline values suitable for moderate traffic (~100-500 concurrent users)

Rationale: Conservative baseline approach with room to scale up. This aligns with industry best practices for starting tuning efforts: begin with proven moderate values, monitor with the existing Prometheus setup, and adjust based on actual traffic patterns. Dev environment will use smaller pools suitable for local development. This approach is safest for production deployment and follows the Spring Boot community's recommended incremental tuning methodology.

Assumption 2: Environment-specific vs. global tuning

Options Considered:

• Single set of tuning parameters in base application.yml for all environments
• Profile-specific configuration files (application-dev.yml, application-prod.yml)
• Base defaults with production overrides only

Chosen Option: Profile-specific configuration files (application-dev.yml, application-prod.yml)

Rationale: Profile-specific configuration files. This directly leverages the existing profile activation infrastructure (start.sh already activates dev/prod profiles based on DEPLOYMENT_GROUP_NAME). It provides clear separation, makes environment differences explicit, and matches the pattern already established with application-monitoring.yml. Developers can easily adjust environment-specific settings without conditional logic or hunting through override chains.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Create Profile-Specific Tuning Configuration Files

Add environment-specific tuning configurations by creating two new YAML files that will be automatically activated by the existing profile system.

Task 1: Create Development Environment Tuning Configuration

Create a new configuration file in src/main/resources/ named application-dev.yml

• Define Tomcat thread pool settings with conservative values suitable for local development (max-threads: 50, min-spare-threads: 10, accept-count: 100)
• Configure HikariCP connection pool with smaller pool sizes appropriate for dev workloads (maximum-pool-size: 10, minimum-idle: 5)
• Set connection lifecycle timeouts aligned with MySQL defaults (max-lifetime: 1,740,000ms to stay under MySQL's 30-min wait_timeout, idle-timeout: 300,000ms)
• Add connection reliability settings (connection-timeout: 20,000ms, validation-timeout: 5,000ms)
• Enable leak detection for development troubleshooting (leak-detection-threshold: 60,000ms)
• Keep MySQL driver settings explicit but minimal since they're already defined in base application.yml

Task 2: Create Production Environment Tuning Configuration

Create a new configuration file in src/main/resources/ named application-prod.yml

• Define Tomcat thread pool settings scaled for production traffic (max-threads: 200, min-spare-threads: 25, accept-count: 200)
• Configure HikariCP connection pool with production-appropriate sizing (maximum-pool-size: 40, minimum-idle: 20 to reduce connection churn)
• Use same connection lifecycle timeouts as dev but with production-optimized validation (max-lifetime: 1,740,000ms, idle-timeout: 600,000ms)
• Set production connection timeout for faster failure detection (connection-timeout: 15,000ms)
• Disable leak detection to avoid monitoring overhead in production (omit leak-detection-threshold)
• Maintain consistency with dev in terms of driver settings and timeout calculations relative to MySQL server configuration

🤖 Prompt for AI agents

Create profile-specific YAML configuration files for development and production
environments.

Create application-dev.yml in src/main/resources/:
- Add Tomcat thread pool configuration with max-threads: 50, min-spare-threads:
10, accept-count: 100
- Add HikariCP connection pool settings with maximum-pool-size: 10,
minimum-idle: 5
- Set connection timeouts: max-lifetime: 1740000ms, idle-timeout: 300000ms,
connection-timeout: 20000ms, validation-timeout: 5000ms
- Enable leak-detection-threshold: 60000ms for development troubleshooting

Create application-prod.yml in src/main/resources/:
- Add Tomcat thread pool configuration with max-threads: 200, min-spare-threads:
25, accept-count: 200
- Add HikariCP connection pool settings with maximum-pool-size: 40,
minimum-idle: 20
- Set connection timeouts: max-lifetime: 1740000ms, idle-timeout: 600000ms,
connection-timeout: 15000ms
- Omit leak-detection-threshold for production

Phase 2: Validation and Documentation

Ensure the tuning configuration integrates properly with existing monitoring and deployment infrastructure.

Task 1: Verify Profile Activation

No code changes needed - validate that the existing start.sh script will correctly activate the new profile-specific configuration files

• Confirm that the profile activation logic in infra/start.sh (lines 6-10 and 24-25) will load application-dev.yml when DEPLOYMENT_GROUP_NAME contains "dev"
• Confirm that application-prod.yml will be loaded when DEPLOYMENT_GROUP_NAME does not contain "dev"
• Verify that Spring's profile inclusion mechanism will properly merge base application.yml with the environment-specific tuning files

Task 2: Update Prometheus Monitoring Configuration

The existing application-monitoring.yml already enables HikariCP metrics through the management endpoints

• Verify that hikaricp.* metrics are available through the existing Prometheus endpoint (no changes needed - HikariCP metrics are auto-registered when pool is configured)
• Ensure tomcat.* thread pool metrics are exposed via the actuator/prometheus endpoint
• Document which metrics to monitor post-deployment (hikaricp.connections.active, hikaricp.connections.idle, tomcat.threads.busy, tomcat.threads.current) to validate tuning effectiveness

Task 3: Document Tuning Rationale and Adjustment Guidelines

Add inline comments within the new configuration files to guide future tuning adjustments

• In application-dev.yml: Comment explaining that values are sized for local development with single-user testing
• In application-prod.yml: Comment explaining baseline production values and referencing the Prometheus metrics that should be monitored for capacity adjustments
• Add comment noting the relationship between HikariCP maximum-pool-size and MySQL max_connections setting (pool size should be significantly lower than database limit, typically leaving headroom for multiple application instances)
• Include guidance on the formula consideration: thread count should align with application concurrency patterns and available CPU cores, following the principle that excessive threads lead to context switching overhead

🤖 Prompt for AI agents

Validate and document the tuning configuration integration.

Add comprehensive inline documentation comments to application-dev.yml:
- Explain values are sized for local development with single-user testing

Add comprehensive inline documentation comments to application-prod.yml:
- Explain baseline production values and reference Prometheus metrics to monitor
(hikaricp.connections.active, hikaricp.connections.idle, tomcat.threads.busy,
tomcat.threads.current)
- Document relationship between HikariCP maximum-pool-size and MySQL
max_connections (pool size should be significantly lower, leaving headroom for
multiple instances)
- Include guidance that thread count should align with concurrency patterns and
available CPU cores to avoid context switching overhead

No changes needed to start.sh or application-monitoring.yml - verify existing
profile activation and metrics exposure work correctly with new configuration
files

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Create profile-specific YAML configuration files for development and production
environments.

Create application-dev.yml in src/main/resources/:
- Add Tomcat thread pool configuration with max-threads: 50, min-spare-threads:
10, accept-count: 100
- Add HikariCP connection pool settings with maximum-pool-size: 10,
minimum-idle: 5
- Set connection timeouts: max-lifetime: 1740000ms, idle-timeout: 300000ms,
connection-timeout: 20000ms, validation-timeout: 5000ms
- Enable leak-detection-threshold: 60000ms for development troubleshooting

Create application-prod.yml in src/main/resources/:
- Add Tomcat thread pool configuration with max-threads: 200, min-spare-threads:
25, accept-count: 200
- Add HikariCP connection pool settings with maximum-pool-size: 40,
minimum-idle: 20
- Set connection timeouts: max-lifetime: 1740000ms, idle-timeout: 600000ms,
connection-timeout: 15000ms
- Omit leak-detection-threshold for production
===============================================================================

Task: 2

Validate and document the tuning configuration integration.

Add comprehensive inline documentation comments to application-dev.yml:
- Explain values are sized for local development with single-user testing

Add comprehensive inline documentation comments to application-prod.yml:
- Explain baseline production values and reference Prometheus metrics to monitor
(hikaricp.connections.active, hikaricp.connections.idle, tomcat.threads.busy,
tomcat.threads.current)
- Document relationship between HikariCP maximum-pool-size and MySQL
max_connections (pool size should be significantly lower, leaving headroom for
multiple instances)
- Include guidance that thread count should align with concurrency patterns and
available CPU cores to avoid context switching overhead

No changes needed to start.sh or application-monitoring.yml - verify existing
profile activation and metrics exposure work correctly with new configuration
files

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- @coderabbitai You can skip phase 3. Add a simple unit test case for phase 2.
- @coderabbitai For assumption 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

Oops, something went wrong! Please try again later. 🐰 💔