docker-compose for services in Spring Boot - Performance & Optimization

Performance: docker-compose for services

MEDIUM IMPACT

This affects the startup time and resource usage of multiple backend services running together, impacting initial load and responsiveness.

Running multiple Spring Boot services together for development

Spring Boot

version: '3.8'
services:
  service1:
    build: ./service1
    ports:
      - "8080:8080"
  service2:
    build: ./service2
    ports:
      - "8081:8081"
    depends_on:
      service1:
        condition: service_healthy
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/actuator/health"]
      interval: 10s
      retries: 5

Using Docker healthchecks allows Docker to manage service readiness without blocking container startup commands.

📈 Performance GainEnables parallel container startup and reduces blocking delays, improving overall startup speed.

Running multiple Spring Boot services together for development

Spring Boot

version: '3.8'
services:
  service1:
    build: ./service1
    ports:
      - "8080:8080"
  service2:
    build: ./service2
    ports:
      - "8081:8081"
    depends_on:
      - service1
    command: ./wait-for-it.sh service1:8080 -- java -jar app.jar

Sequential startup with wait scripts delays overall readiness and blocks parallel container initialization.

📉 Performance CostBlocks startup for service2 until service1 is ready, increasing total startup time by several seconds.

Performance Comparison

Pattern	Container Startup	Blocking	Resource Usage	Verdict
Sequential wait-for-it script	Serial startup	Blocks dependent services	Higher due to idle wait	[X] Bad
Healthcheck with depends_on	Parallel startup	Non-blocking	Efficient resource use	[OK] Good

Rendering Pipeline

Docker-compose orchestrates container startup and networking before the Spring Boot services begin handling requests, affecting backend readiness but not browser rendering directly.

→Container Initialization

→Service Startup

→Network Setup

⚠️ BottleneckService startup blocking due to improper dependency handling

Optimization Tips

1Avoid blocking dependent services with scripts; use Docker healthchecks instead.

2Configure healthchecks to allow parallel container startup and faster overall readiness.

3Monitor container health and startup logs to detect and fix startup delays.

Performance Quiz - 3 Questions

What is a performance downside of using a wait-for-it script in docker-compose for dependent services?

A It reduces container image size

B It blocks dependent services from starting until the main service is ready

C It improves network latency between services

D It automatically scales services

DevTools: Docker CLI and docker-compose logs

How to check: Run 'docker-compose up' with logs enabled; observe service startup order and delays; use 'docker ps' to check container states and health status.

What to look for: Look for containers stuck in starting or unhealthy states indicating blocking or failed healthchecks.

Practice

1. What is the main purpose of using docker-compose with Spring Boot services?

easy

A. To run multiple related services together with one configuration file

B. To compile Java code faster

C. To replace the Spring Boot framework

D. To write unit tests automatically

Solution

1. Step 1: Understand what docker-compose does

   Docker Compose is a tool to run multiple containers (services) together using one YAML file.

2. Step 2: Relate to Spring Boot services

   It helps run your Spring Boot app alongside databases or other services easily.

3. Final Answer:

   To run multiple related services together with one configuration file -> Option A

4. Quick Check:

   docker-compose = run multiple services [OK]

Hint: Remember: docker-compose manages multiple containers easily [OK]

Common Mistakes:

• Thinking docker-compose compiles code
• Confusing docker-compose with testing tools
• Believing it replaces Spring Boot

2. Which of the following is the correct way to specify a service's port mapping in a docker-compose.yml file?

easy

A. ports: - "8080:8080"

B. ports: 8080:8080

C. port: 8080->8080

D. expose: 8080:8080

Solution

1. Step 1: Recall docker-compose port syntax

   Ports are listed as a YAML array with dash and quotes, like ports: - "hostPort:containerPort".

2. Step 2: Check options

   ports: - "8080:8080" matches the correct YAML syntax for port mapping.

3. Final Answer:

   ports: - "8080:8080" -> Option A

4. Quick Check:

   Port mapping uses dash and quotes in YAML [OK]

Hint: Use dash and quotes for ports in docker-compose YAML [OK]

Common Mistakes:

• Omitting dash for list items
• Using wrong key 'port' instead of 'ports'
• Confusing 'expose' with 'ports'

3. Given this docker-compose.yml snippet:

services:
  app:
    image: springboot-app
    ports:
      - "8080:8080"
    depends_on:
      - db
  db:
    image: postgres
    environment:
      POSTGRES_PASSWORD: example

What happens when you run docker-compose up?

medium

A. docker-compose throws a syntax error

B. Only app service starts, db is ignored

C. db starts but app fails due to missing environment

D. Both app and db services start, app waits for db to start

Solution

1. Step 1: Understand depends_on behavior

   The app service depends on db, so docker-compose starts db first, then app.

2. Step 2: Check environment and ports

   db has required environment variable, app exposes port 8080 correctly.

3. Final Answer:

   Both app and db services start, app waits for db to start -> Option D

4. Quick Check:

   depends_on starts dependencies first [OK]

Hint: depends_on starts services in order, no syntax errors here [OK]

Common Mistakes:

• Assuming depends_on waits for full readiness
• Thinking db is ignored without explicit start
• Confusing environment variables with ports

4. You wrote this docker-compose.yml but your Spring Boot app fails to connect to the database:

services:
  app:
    image: springboot-app
    ports:
      - "8080:8080"
    environment:
      SPRING_DATASOURCE_URL: jdbc:postgresql://localhost:5432/mydb
  db:
    image: postgres
    environment:
      POSTGRES_PASSWORD: example

What is the likely problem?

medium

A. POSTGRES_PASSWORD is incorrect environment variable

B. Missing port mapping for db service

C. The app tries to connect to localhost instead of the db service hostname

D. The app image name is wrong

Solution

1. Step 1: Check datasource URL in app environment

   The app uses jdbc URL with 'localhost', which inside container means itself, not db service.

2. Step 2: Understand docker-compose networking

   Services communicate by service name, so URL should use 'db' hostname, not 'localhost'.

3. Final Answer:

   The app tries to connect to localhost instead of the db service hostname -> Option C

4. Quick Check:

   Use service name, not localhost, for inter-service DB URL [OK]

Hint: Use service names, not localhost, inside docker-compose networks [OK]

Common Mistakes:

• Assuming localhost works inside containers
• Forgetting to map ports for external access
• Misnaming environment variables

5. You want to run a Spring Boot app with a MySQL database using docker-compose. You want the database to keep data even if the container stops. Which snippet correctly adds persistent storage for the database?

hard

A. volumes:
- /var/lib/mysql:/db-data

volumes:
db-data:

B. volumes:
- db-data:/var/lib/mysql

volumes:
db-data:

C. volumes:
- db-data:/mysql/data

volumes:
mysql-data:

D. volumes:
- /mysql/data:/db-data

volumes:
db-data:

Solution

1. Step 1: Understand volume syntax for persistence

   Docker volumes map a named volume to the container path where data is stored, e.g., db-data:/var/lib/mysql.

2. Step 2: Check volume declaration

   The named volume must be declared under top-level volumes: with the same name.

3. Final Answer:

   volumes: - db-data:/var/lib/mysql volumes: db-data: -> Option B

4. Quick Check:

   Named volume mapped to container path with declaration [OK]

Hint: Map named volume to container data path and declare it below [OK]

Common Mistakes:

• Reversing host and container paths
• Not declaring the named volume
• Using wrong container data directory