Spring Boot 가상 스레드와 Tomcat 스레드 풀 설정 영향 분석 결과

목적: Spring Boot에서 가상 스레드(Virtual Threads) 활성화가 Tomcat 스레드 풀 설정에 미치는 영향을 실증적으로 분석
가설: 가상 스레드 활성화 시에도 Tomcat 스레드 풀 설정이 여전히 필요하고 성능에 영향을 미칠 것
결론: 가상 스레드는 Tomcat 스레드 풀 제한을 완전히 우회함, 가상 스레드 true 지정 시 tomcat 설정이 무효화됨

실험 환경

시스템 정보

• Java: OpenJDK 21.0.2
• Spring Boot: 3.4.3
• 서버: 내장 Tomcat 10.1.36
• 테스트 gateway, engine : 192.168.2.13:8751, 192.168.2.13:8731

테스트 설정

engine-mvc-dev.yaml

server:
  shutdown: graceful
  tomcat:
    accept-count: 3000
    max-connections: 10000
    threads:
      max: 1 
      min-spare: 1 

spring:
  threads:
    virtual:
      enabled: true/false (실험에 따라 변경)

실험 과정 및 결과

1단계: 초기 메트릭 조사

목적: 가상 스레드 환경에서 기존 모니터링 도구의 동작 확인

방법: Spring Boot Actuator 메트릭 엔드포인트 조사

• /actuator/metrics/tomcat.threads.config.max
• /actuator/metrics/executor.pool.max
• /actuator/metrics/jvm.threads.live

결과:

• 모든 Tomcat 스레드 관련 메트릭에서 measurements: [] (빈 배열)
• 기존 스레드 풀 모니터링 도구가 가상 스레드 환경에서 작동하지 않음
• JVM 로그에서 java.lang.VirtualThread.run() 확인으로 가상 스레드 실행 검증

2단계: 가벼운 엔드포인트 부하 테스트

테스트 대상: /actuator/health (즉시 응답하는 가벼운 요청)

가상 스레드 활성화 상태에서 50개 동시 요청

for i in {1..50}; do curl -w "%{time_total}\\n" -s <http://192.168.2.13:8751/actuator/health> & done; wait

결과:

• 모든 요청 성공 (100% 성공률)
• 응답 시간: 0.011초 ~ 0.048초 (일관적)
• 설정된 max: 10 제한을 완전히 무시

가상 스레드 비활성화 후 200개 동시 요청

for i in {1..200}; do curl -s <http://192.168.2.13:8751/actuator/health> > /dev/null & done; wait

결과:

• 200개 요청 모두 성공
• Tomcat NIO Connector의 특성상 가벼운 요청은 스레드 제한 영향을 받지 않음

3단계: 무거운 엔드포인트를 통한 결정적 테스트

테스트 대상: /sh/test (SSE 스트리밍, 약 3초 지속)

3-1. 가상 스레드 비활성화 + 극단적 제한 (max: 1, min-spare: 1)

10개 동시 요청 결과:

응답 시간 패턴:
- 1-5번째: ~3.08초 (거의 동시)
- 6번째: 3.35초 (+0.27초)
- 7번째: 3.66초 (+0.31초)
- 8번째: 3.97초 (+0.31초)
- 9번째: 4.27초 (+0.30초)
- 10번째: 4.58초 (+0.31초)

분석: 명확한 순차적 처리 패턴, 스레드 풀 포화로 인한 큐잉 효과 확인

3-2. 가상 스레드 활성화 + 동일 설정 (max: 1, min-spare: 1)

10개 동시 요청 결과:

응답 시간:
- 모든 요청: 1.816초 ~ 1.821초
- 최대 편차: 0.005초 (무시할 수 있는 수준)

분석: 완전한 병렬 처리, Tomcat 스레드 제한 완전 우회

4단계 max-connections, accept-count : 제한 테스트

4-1. max-connections 제한 테스트

테스트 방법:

• 연결 한계 테스트
• 실시간 연결 수 모니터링: watch "netstat -an | grep :8751 | wc -l"

결과:

연결 수 변화:
- 테스트 시작: 기준선 연결 수
- 테스트 중: 15,850개 연결까지 증가
- 설정값 초과: max-connections: 10000을 58% 초과

분석:

• 설정 무효화: max-connections: 10000 제한이 실제로 적용되지 않음
• 무제한 연결: 시스템 리소스 한계까지 연결 수용

4-2. accept-count 제한 테스트

설정: accept-count: 3000 (연결 대기열 크기 제한)

테스트 분석:

• 이미 max-connections 제한이 무효화된 상태에서 accept-count 제한도 우회됨
• 15,850개 연결은 max-connections(10,000) + accept-count(3,000) = 13,000을 초과
• 연결 대기열 제한 역시 가상 스레드 환경에서 무효화

결론

가상 스레드 환경에서는 기존 Tomcat 스레드 메트릭이 수집되지 않아 전통적인 모니터링 방식이 무효화됨
가상 스레드 true 지정 시 tomcat 설정이 무효화됨