1. 동일한 코드, 4배의 성능 차이

[Phase 2] 테스트를 마친 후, 스레드 덤프를 확보하기 위해 설정 변경 없이 동일한 테스트를 한 번 더 실행했다. 그런데 결과는 충격적이었다.

코드 한 줄, 설정 값 하나 바꾸지 않았는데 처리량(TPS)은 4배가 뛰었고, CPU는 85% 까지 치면서 과부화가 걸렸다. 이 현상을 보고 가장 먼저 생각난 부분은 두 가지 였다.

1. Redis Cache Hit 율
   • 첫 번째 테스트는 캐시가 비어있어 DB 조회가 발생할수 밖에 없다.
   • 두 번째 테스트에서는 동일한 테스트 스크립트 + 동일한 요청이므로, 거의 100% 의 캐시 hit 로 인해 조회 DB I/O가 제거되었을 것이다.
2. JVM Warm Up
   • JVM이 첫 번째 테스트 수행 과정을 학습하여, 두 번째 테스트 시점에는 주요 로직을 최적화했을 것이다.

이 가설을 검증하기 위해 **Redis 모니터링 지표**와 **JIT 컴파일 로그**를 분석했다.

검증 1: Redis Cache Hit

가장 먼저 의심한 것은 I/O 병목의 해소 여부였다. Grafana를 통해 Redis의 Hits / Misses 지표를 비교해보았다.

Cold vs Warm-up Redis 지표 비교

• 왼쪽 (Cold Test)

  • 노란선(Misses): 초당 약 150회 발생.
  • 초록선(Hits): 거의 바닥(0)에 머무름.

  캐시가 비어있었기 때문에 요청이 들어오는 족족 DB로 흘러갔다. 즉, 초당 150번의 DB 조회(Disk I/O)가 시스템 전체 속도를 제한하고 있었다고 해석할 수 있다.

• 오른쪽 (Warm-up Test)

  • 노란선(Misses): 0임.
  • 초록선(Hits): 초당 2,100회 이상으로 치솟음.
  • 모든 데이터 조회가 메모리 레벨에서 처리되었다. 즉, I/O 처리량이 물리적으로 14배 이상 증가했다고 해석할 수 있다.